From edewata at redhat.com Tue May 1 00:09:40 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 30 Apr 2012 19:09:40 -0500 Subject: [Pki-devel] PATCH 0029 - RESTful servlet to configure system in a single servlet In-Reply-To: <1335469796.24014.3.camel@alee-workpc> References: <1335469796.24014.3.camel@alee-workpc> Message-ID: <4F9F29C4.2070704@redhat.com> On 4/26/2012 2:49 PM, Ade Lee wrote: > Please review: > > New RESTful servlet that does system configuration in a single servlet. > > Installation code common to the panels and the installation servlet are extracted to a > ConfigurationUtils file. The panel code will be cleaned up to use the code in this > class in a later commit. > > Contains restful client and test driver code. The test driver code should be modified > and placed in a junit/system test framework. Installation has been tested to work with > the following installations: master CA, clone CA, KRA, OCSP, TKS, subordinate CA, CA > signed by external CA (parts 1 and 2). > > Ticket #155 > > Thanks, > Ade Here's some initial feedback: 1. The ConfigurationErrorInterceptor is basically identical to the existing DRMErrorInterceptor. To avoid duplicating the code for each test components we can move the DRMErrorInterceptor from the base/kra/functional into the base/test and call it CMSErrorInterceptor (or something like that) which then can be used by all test components. Or we can put it into the common package so it can be used by any clients including the test tools. Ideally it should be put into a separate jar file that contains the client libraries only. 2. Classes such as ConfigurationTest and ConfigurationUtils are defined as containers of static functions. It might be possible to convert these static functions into object methods and the parameters can be passed as attributes, for example: public class ConfigurationTest { String host; public void parse(...) { host = cmd.getOptionValue("h"); } public static void main(String args[]) { ConfigurationTest test = new ConfigurationTest(); test.parse(args); ConfigurationData data = test.construct(); ... } } 3. The ConfigurationUtils.getDomainXML() returns an XML string, but before it's used it's always parsed into DOM. It might be better to modify this method to return DOM directly. Is the XML string equivalent to DomainInfo class? If that's the case the method can also return a DomainInfo directly. 4. It might be possible to convert some fields in ConfigurationData such as dsPort or isClone into integer or boolean. 5. In InstallTokenRequest constructors the super() invocations aren't necessary. 6. The SystemConfigurationResourceService contains a static variable mRandom. The 'static' and the 'm' prefix don't seem to be necessary. 7. The auto-format doesn't seem to be working. There are some trailing whitespaces too. Eclipse should have fixed it automatically. -- Endi S. Dewata From cfu at redhat.com Tue May 1 15:42:47 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 01 May 2012 08:42:47 -0700 Subject: [Pki-devel] patches for review - Bug 744207 - Key archival fails when KRA is configured with lunasa Message-ID: <4FA00477.5060205@redhat.com> Please review the following patches for *Bug 744207* -Key archival fails when KRA is configured with lunasa: JSS: https://bugzilla.redhat.com/attachment.cgi?id=581108&action=diff&context=patch&collapsed=&headers=1&format=raw DRM/KRA: https://bugzilla.redhat.com/attachment.cgi?id=581109&action=diff&context=patch&collapsed=&headers=1&format=raw The JSS patch alone allows key archival (both RSA and ECC) to work with lunasa token where the lunasa token has to be KE-capable. Work done specifically on the following model: Model: Luna SA v5 w/ PED auth and CKE Part No: 908-000093-001 The DRM/KRA patch are just some debugging to make recovery debugging easier with an addition of non-static salt. The recovery is not working currently, failing with wrapping operation during PBE creation: *Bug 817423* -Key recovery fails when KRA is configured with lunasa which will be fixed at a later time. To test these patches for key archival on the said model of lunasa, one must turn on the prototype mode for recovery. thanks, Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue May 1 15:57:53 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 01 May 2012 11:57:53 -0400 Subject: [Pki-devel] PATCH 0029 - RESTful servlet to configure system in a single servlet In-Reply-To: <4F9F29C4.2070704@redhat.com> References: <1335469796.24014.3.camel@alee-workpc> <4F9F29C4.2070704@redhat.com> Message-ID: <1335887874.21539.15.camel@aleeredhat.laptop> On Mon, 2012-04-30 at 19:09 -0500, Endi Sukma Dewata wrote: > On 4/26/2012 2:49 PM, Ade Lee wrote: > > Please review: > > > > New RESTful servlet that does system configuration in a single servlet. > > > > Installation code common to the panels and the installation servlet are extracted to a > > ConfigurationUtils file. The panel code will be cleaned up to use the code in this > > class in a later commit. > > > > Contains restful client and test driver code. The test driver code should be modified > > and placed in a junit/system test framework. Installation has been tested to work with > > the following installations: master CA, clone CA, KRA, OCSP, TKS, subordinate CA, CA > > signed by external CA (parts 1 and 2). > > > > Ticket #155 > > > > Thanks, > > Ade > > Here's some initial feedback: > > 1. The ConfigurationErrorInterceptor is basically identical to the > existing DRMErrorInterceptor. To avoid duplicating the code for each > test components we can move the DRMErrorInterceptor from the > base/kra/functional into the base/test and call it CMSErrorInterceptor > (or something like that) which then can be used by all test components. > Or we can put it into the common package so it can be used by any > clients including the test tools. Ideally it should be put into a > separate jar file that contains the client libraries only. > I agree with this completely. We will need to extract these interfaces and model classes and put them in a common package for use by both servers and clients. This includes putting all the common code (the interceptors and the common jss connection code). I suggest we check this code in - as well as Jack's code for the CA, and then create a task to do this consolidation. I'll create the task. > 2. Classes such as ConfigurationTest and ConfigurationUtils are defined > as containers of static functions. It might be possible to convert these > static functions into object methods and the parameters can be passed as > attributes, for example: > > public class ConfigurationTest { > > String host; > > public void parse(...) { > host = cmd.getOptionValue("h"); > } > > public static void main(String args[]) { > ConfigurationTest test = new ConfigurationTest(); > test.parse(args); > ConfigurationData data = test.construct(); > ... > } > } > We could certainly do that for ConfigurationTest - although I think we may want to consider changing ConfigurationTest to some sort of junit test. The purpose of ConfigurationTest was just to get something quick and dirty up to test the new servlet and provide a model for the pkicreate configure script. ConfigurationUtils is supposed to be used as a common set of functions for both the new servlet and the installation panels. In fact, basically what this patch does is extract (and clean up a bit) all the old logic in the installation panels and put them in a common place (ConfigurationUtils). My next set of patches will replace the logic in the existing panels to calls in ConfigurationUtils. You can't really keep objects around from panel to panel - so these really are static functions. And I'm not sure what that would buy you .. > 3. The ConfigurationUtils.getDomainXML() returns an XML string, but > before it's used it's always parsed into DOM. It might be better to > modify this method to return DOM directly. Is the XML string equivalent > to DomainInfo class? If that's the case the method can also return a > DomainInfo directly. > In the panels, we will want to return the string for storage in CS.cfg. See next patch. > 4. It might be possible to convert some fields in ConfigurationData such > as dsPort or isClone into integer or boolean. > Yeah, I agree. I figured you would pick up on that. Let me open that as a separate task. > 5. In InstallTokenRequest constructors the super() invocations aren't > necessary. > Will remove. > 6. The SystemConfigurationResourceService contains a static variable > mRandom. The 'static' and the 'm' prefix don't seem to be necessary. > agreed - will fix. > 7. The auto-format doesn't seem to be working. There are some trailing > whitespaces too. Eclipse should have fixed it automatically. > Weird .. maybe the trailing whitespaces are in web.xml and other config files? I'll check it out .. From cfu at redhat.com Tue May 1 15:58:52 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 01 May 2012 08:58:52 -0700 Subject: [Pki-devel] patch for review - Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf Message-ID: <4FA0083C.4000907@redhat.com> Please review the following patch for the bug: *Bug 640046* -TPS installation wizard: unsupported module not logged in with password in password.conf tps-ui: https://bugzilla.redhat.com/attachment.cgi?id=581291&action=diff&context=patch&collapsed=&headers=1&format=raw This patch allows config panel ModulePanel to log into "Other Modules" (unsupported modules). Also to note: the modules modules appear to be stored in pwcache.conf, not password.conf. thanks, Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Tue May 1 17:49:42 2012 From: jmagne at redhat.com (John Magne) Date: Tue, 01 May 2012 13:49:42 -0400 (EDT) Subject: [Pki-devel] patch for review - Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf In-Reply-To: <4FA0083C.4000907@redhat.com> Message-ID: ACK Very simple fix to provide (for unsupported modules) functional parity with what is done with supported modules. I'm guessing we probably need a bug for the RA too. ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, May 1, 2012 8:58:52 AM Subject: [Pki-devel] patch for review - Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf Please review the following patch for the bug: Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf tps-ui: https://bugzilla.redhat.com/attachment.cgi?id=581291&action=diff&context=patch&collapsed=&headers=1&format=raw This patch allows config panel ModulePanel to log into "Other Modules" (unsupported modules). Also to note: the modules modules appear to be stored in pwcache.conf, not password.conf. thanks, Christina _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue May 1 21:18:26 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 01 May 2012 17:18:26 -0400 Subject: [Pki-devel] [PATCH] patches 30/31 to refactor installation panels Message-ID: <1335907106.7559.6.camel@alee-workpc> Common code has been moved to ConfigurationUtils. These patches refactor the existing installation servlets to use that common code. (So lots of now duplicate code being deleted). I think this makes the code a lot simpler to follow. In addition, a bunch of obsolete servlets have been removed in patch 31. Installations have been tested in the following scenarios: ca, clone ca, ca subordinate to external ca, kra, ocsp, tks. The patches need to be rebased on top of patch 29 -- which I plan to check in in any case. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0030-Refactor-installation-servlets-to-use-common-code-in.patch Type: text/x-patch Size: 367595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0031-Removed-obsolete-installation-servlets.patch Type: text/x-patch Size: 140092 bytes Desc: not available URL: From alee at redhat.com Tue May 1 21:24:22 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 01 May 2012 17:24:22 -0400 Subject: [Pki-devel] PATCH 0029 - RESTful servlet to configure system in a single servlet In-Reply-To: <1335887874.21539.15.camel@aleeredhat.laptop> References: <1335469796.24014.3.camel@alee-workpc> <4F9F29C4.2070704@redhat.com> <1335887874.21539.15.camel@aleeredhat.laptop> Message-ID: <1335907463.2247.0.camel@aleeredhat.laptop> pushed to master. Thanks! On Tue, 2012-05-01 at 11:57 -0400, Ade Lee wrote: > On Mon, 2012-04-30 at 19:09 -0500, Endi Sukma Dewata wrote: > > On 4/26/2012 2:49 PM, Ade Lee wrote: > > > Please review: > > > > > > New RESTful servlet that does system configuration in a single servlet. > > > > > > Installation code common to the panels and the installation servlet are extracted to a > > > ConfigurationUtils file. The panel code will be cleaned up to use the code in this > > > class in a later commit. > > > > > > Contains restful client and test driver code. The test driver code should be modified > > > and placed in a junit/system test framework. Installation has been tested to work with > > > the following installations: master CA, clone CA, KRA, OCSP, TKS, subordinate CA, CA > > > signed by external CA (parts 1 and 2). > > > > > > Ticket #155 > > > > > > Thanks, > > > Ade > > > > Here's some initial feedback: > > > > 1. The ConfigurationErrorInterceptor is basically identical to the > > existing DRMErrorInterceptor. To avoid duplicating the code for each > > test components we can move the DRMErrorInterceptor from the > > base/kra/functional into the base/test and call it CMSErrorInterceptor > > (or something like that) which then can be used by all test components. > > Or we can put it into the common package so it can be used by any > > clients including the test tools. Ideally it should be put into a > > separate jar file that contains the client libraries only. > > > I agree with this completely. We will need to extract these interfaces > and model classes and put them in a common package for use by both > servers and clients. This includes putting all the common code (the > interceptors and the common jss connection code). I suggest we check > this code in - as well as Jack's code for the CA, and then create a task > to do this consolidation. I'll create the task. > > > 2. Classes such as ConfigurationTest and ConfigurationUtils are defined > > as containers of static functions. It might be possible to convert these > > static functions into object methods and the parameters can be passed as > > attributes, for example: > > > > public class ConfigurationTest { > > > > String host; > > > > public void parse(...) { > > host = cmd.getOptionValue("h"); > > } > > > > public static void main(String args[]) { > > ConfigurationTest test = new ConfigurationTest(); > > test.parse(args); > > ConfigurationData data = test.construct(); > > ... > > } > > } > > > We could certainly do that for ConfigurationTest - although I think we > may want to consider changing ConfigurationTest to some sort of junit > test. The purpose of ConfigurationTest was just to get something quick > and dirty up to test the new servlet and provide a model for the > pkicreate configure script. > > ConfigurationUtils is supposed to be used as a common set of functions > for both the new servlet and the installation panels. In fact, basically > what this patch does is extract (and clean up a bit) all the old logic > in the installation panels and put them in a common place > (ConfigurationUtils). My next set of patches will replace the logic in > the existing panels to calls in ConfigurationUtils. > > You can't really keep objects around from panel to panel - so these > really are static functions. And I'm not sure what that would buy > you .. > > > 3. The ConfigurationUtils.getDomainXML() returns an XML string, but > > before it's used it's always parsed into DOM. It might be better to > > modify this method to return DOM directly. Is the XML string equivalent > > to DomainInfo class? If that's the case the method can also return a > > DomainInfo directly. > > > In the panels, we will want to return the string for storage in CS.cfg. > See next patch. > > > 4. It might be possible to convert some fields in ConfigurationData such > > as dsPort or isClone into integer or boolean. > > > Yeah, I agree. I figured you would pick up on that. Let me open that > as a separate task. > > > 5. In InstallTokenRequest constructors the super() invocations aren't > > necessary. > > > Will remove. > > > 6. The SystemConfigurationResourceService contains a static variable > > mRandom. The 'static' and the 'm' prefix don't seem to be necessary. > > > agreed - will fix. > > > 7. The auto-format doesn't seem to be working. There are some trailing > > whitespaces too. Eclipse should have fixed it automatically. > > > Weird .. maybe the trailing whitespaces are in web.xml and other config > files? I'll check it out .. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Tue May 1 22:11:19 2012 From: jmagne at redhat.com (John Magne) Date: Tue, 01 May 2012 18:11:19 -0400 (EDT) Subject: [Pki-devel] patches for review - Bug 744207 - Key archival fails when KRA is configured with lunasa In-Reply-To: <4FA00477.5060205@redhat.com> Message-ID: ACK Patches address wrapping on Luna and improve error handling and logging. ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, May 1, 2012 8:42:47 AM Subject: [Pki-devel] patches for review - Bug 744207 - Key archival fails when KRA is configured with lunasa Please review the following patches for Bug 744207 - Key archival fails when KRA is configured with lunasa: JSS: https://bugzilla.redhat.com/attachment.cgi?id=581108&action=diff&context=patch&collapsed=&headers=1&format=raw DRM/KRA: https://bugzilla.redhat.com/attachment.cgi?id=581109&action=diff&context=patch&collapsed=&headers=1&format=raw The JSS patch alone allows key archival (both RSA and ECC) to work with lunasa token where the lunasa token has to be KE-capable. Work done specifically on the following model: Model: Luna SA v5 w/ PED auth and CKE Part No: 908-000093-001 The DRM/KRA patch are just some debugging to make recovery debugging easier with an addition of non-static salt. The recovery is not working currently, failing with wrapping operation during PBE creation: Bug 817423 - Key recovery fails when KRA is configured with lunasa which will be fixed at a later time. To test these patches for key archival on the said model of lunasa, one must turn on the prototype mode for recovery. thanks, Christina _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Tue May 1 22:54:37 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 01 May 2012 15:54:37 -0700 Subject: [Pki-devel] patch pushed - Re: patch for review - Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf In-Reply-To: References: Message-ID: <4FA069AD.8000304@redhat.com> pushed to DOGTAG_9_BRANCH tps-ui]$ git push Counting objects: 21, done. Delta compression using up to 2 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (11/11), 956 bytes, done. Total 11 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/pki.git df46c7f..98fed48 DOGTAG_9_BRANCH -> DOGTAG_9_BRANCH On 05/01/2012 10:49 AM, John Magne wrote: > ACK > > Very simple fix to provide (for unsupported modules) functional parity with what is done with supported modules. > > > I'm guessing we probably need a bug for the RA too. > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, May 1, 2012 8:58:52 AM > Subject: [Pki-devel] patch for review - Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf > > > Please review the following patch for the bug: Bug 640046 - TPS installation wizard: unsupported module not logged in with password in password.conf > > tps-ui: > https://bugzilla.redhat.com/attachment.cgi?id=581291&action=diff&context=patch&collapsed=&headers=1&format=raw > > This patch allows config panel ModulePanel to log into "Other Modules" (unsupported modules). > Also to note: the modules modules appear to be stored in pwcache.conf, not password.conf. > > thanks, > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed May 2 01:05:28 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 01 May 2012 20:05:28 -0500 Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: <889ec163-51d7-4f3a-b351-243f8d8546eb@zmail15.collab.prod.int.phx2.redhat.com> References: <889ec163-51d7-4f3a-b351-243f8d8546eb@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4FA08858.2010103@redhat.com> On 4/30/2012 1:53 PM, John Magne wrote: > Provide CA EE Restful interface and test client. > > Tickets #144 and #145 > Providing the following: > > 1. Simple EE restful interface for certificates, printing, listing and searching. > 2. Simple EE restful interface for certificate enrollment requests. > 3. Simple EE restful interface for profiles and profile properties. > 4. Simple Test client to exercise the functionality. > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > 6. Provide simple restful implementations of new interfaces added. > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > in the DRM restful area. > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. Some feedback: 1. The CMSRestClient could be moved into base/common/src/com/netscape/cms/servlet/csadmin, which can be used by any clients including the test tools. 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can merge these classes into CMSErrorInterceptor and place it in the same package as CMSRestClient. The interceptor can be added in the CMSRestClient, so the subclasses don't need to do that. 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be more than 1, so the code could be simplified. 4. In CertDAO.getCertChainData() the certsInChain array is allocated multiple times. It should be possible to use the loop to determine the length first, then allocate the array just once after that. 5. Also in CertDAO.getCertChainData() after the initialization loop it looks like the certsInChain may contain a null value if x509cert exists in mCACerts but not the last element. Is that case possible? 6. The CertSearchData.escapeValueRfc1779() probably can be moved into LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into LDAPUtil.escapeFilter(). 7. In CertSearchData.build*Filter() it's not necessary to use "this." when calling other methods of the same object. It's possible to use the fields directly too. 8. In CertSearchData.build*Filter() the values should be escaped to avoid injection attack: filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + ")"); 9. In CertSearchData.buildAVAFilter() the code does a double escape with the escape DN method. I think it should use 2 different escape methods, one for the DN and the other for the filter. So the code would look like this: lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); Could you try creating some certs with this common name "E*Corp, Inc." and "E-Corp, Inc." and see if it can find an exact match. The escapeFilter() should escape the '*'. 10. There are some formatting issues and trailing whitespaces. Auto-formatting probably will fix this. -- Endi S. Dewata From jmagne at redhat.com Wed May 2 17:24:04 2012 From: jmagne at redhat.com (John Magne) Date: Wed, 02 May 2012 13:24:04 -0400 (EDT) Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: <4FA08858.2010103@redhat.com> Message-ID: Great stuff, thanks. I will look into the ones you had questions about. ----- Original Message ----- From: "Endi Sukma Dewata" To: pki-devel at redhat.com, "John Magne" Sent: Tuesday, May 1, 2012 6:05:28 PM Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch On 4/30/2012 1:53 PM, John Magne wrote: > Provide CA EE Restful interface and test client. > > Tickets #144 and #145 > Providing the following: > > 1. Simple EE restful interface for certificates, printing, listing and searching. > 2. Simple EE restful interface for certificate enrollment requests. > 3. Simple EE restful interface for profiles and profile properties. > 4. Simple Test client to exercise the functionality. > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > 6. Provide simple restful implementations of new interfaces added. > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > in the DRM restful area. > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. Some feedback: 1. The CMSRestClient could be moved into base/common/src/com/netscape/cms/servlet/csadmin, which can be used by any clients including the test tools. 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can merge these classes into CMSErrorInterceptor and place it in the same package as CMSRestClient. The interceptor can be added in the CMSRestClient, so the subclasses don't need to do that. 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be more than 1, so the code could be simplified. 4. In CertDAO.getCertChainData() the certsInChain array is allocated multiple times. It should be possible to use the loop to determine the length first, then allocate the array just once after that. 5. Also in CertDAO.getCertChainData() after the initialization loop it looks like the certsInChain may contain a null value if x509cert exists in mCACerts but not the last element. Is that case possible? 6. The CertSearchData.escapeValueRfc1779() probably can be moved into LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into LDAPUtil.escapeFilter(). 7. In CertSearchData.build*Filter() it's not necessary to use "this." when calling other methods of the same object. It's possible to use the fields directly too. 8. In CertSearchData.build*Filter() the values should be escaped to avoid injection attack: filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + ")"); 9. In CertSearchData.buildAVAFilter() the code does a double escape with the escape DN method. I think it should use 2 different escape methods, one for the DN and the other for the filter. So the code would look like this: lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); Could you try creating some certs with this common name "E*Corp, Inc." and "E-Corp, Inc." and see if it can find an exact match. The escapeFilter() should escape the '*'. 10. There are some formatting issues and trailing whitespaces. Auto-formatting probably will fix this. -- Endi S. Dewata From jmagne at redhat.com Thu May 3 00:05:38 2012 From: jmagne at redhat.com (John Magne) Date: Wed, 02 May 2012 20:05:38 -0400 (EDT) Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: <4FA08858.2010103@redhat.com> Message-ID: Revised patch as per the suggestions below: All the suggestions made sense and I implemented them as suggested. Tests ran fine. Questions from below: 5. Also in CertDAO.getCertChainData() after the initialization loop it looks like the certsInChain may contain a null value if x509cert exists in mCACerts but not the last element. Is that case possible? I could not see this scenario. What the code is doing is checking to see if you are trying to get the cert chain of a cert that is already a member of the CA's cert chain. In that case, the size of the array will be the size of the CA's cert chain. If this is not the case, the size of the array will be that value plus one. 9. Could you try creating some certs with this common name "E*Corp, Inc." and "E-Corp, Inc." and see if it can find an exact match. The escapeFilter() should escape the '*'. I tried this after the fixes and was able to get an exact match on "E*Corp, Inc". ----- Original Message ----- From: "Endi Sukma Dewata" To: pki-devel at redhat.com, "John Magne" Sent: Tuesday, May 1, 2012 6:05:28 PM Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch On 4/30/2012 1:53 PM, John Magne wrote: > Provide CA EE Restful interface and test client. > > Tickets #144 and #145 > Providing the following: > > 1. Simple EE restful interface for certificates, printing, listing and searching. > 2. Simple EE restful interface for certificate enrollment requests. > 3. Simple EE restful interface for profiles and profile properties. > 4. Simple Test client to exercise the functionality. > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > 6. Provide simple restful implementations of new interfaces added. > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > in the DRM restful area. > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. Some feedback: 1. The CMSRestClient could be moved into base/common/src/com/netscape/cms/servlet/csadmin, which can be used by any clients including the test tools. 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can merge these classes into CMSErrorInterceptor and place it in the same package as CMSRestClient. The interceptor can be added in the CMSRestClient, so the subclasses don't need to do that. 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be more than 1, so the code could be simplified. 4. In CertDAO.getCertChainData() the certsInChain array is allocated multiple times. It should be possible to use the loop to determine the length first, then allocate the array just once after that. 5. Also in CertDAO.getCertChainData() after the initialization loop it looks like the certsInChain may contain a null value if x509cert exists in mCACerts but not the last element. Is that case possible? 6. The CertSearchData.escapeValueRfc1779() probably can be moved into LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into LDAPUtil.escapeFilter(). 7. In CertSearchData.build*Filter() it's not necessary to use "this." when calling other methods of the same object. It's possible to use the fields directly too. 8. In CertSearchData.build*Filter() the values should be escaped to avoid injection attack: filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + ")"); 9. In CertSearchData.buildAVAFilter() the code does a double escape with the escape DN method. I think it should use 2 different escape methods, one for the DN and the other for the filter. So the code would look like this: lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); Could you try creating some certs with this common name "E*Corp, Inc." and "E-Corp, Inc." and see if it can find an exact match. The escapeFilter() should escape the '*'. 10. There are some formatting issues and trailing whitespaces. Auto-formatting probably will fix this. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Provide-CA-EE-Restful-interface-and-test-client.patch Type: text/x-patch Size: 177358 bytes Desc: not available URL: From cfu at redhat.com Thu May 3 00:51:29 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 02 May 2012 17:51:29 -0700 Subject: [Pki-devel] patch pushed - Re: patches for review - Bug 744207 - Key archival fails when KRA is configured with lunasa In-Reply-To: References: Message-ID: <4FA1D691.9090006@redhat.com> patch pushed to DOGTAG_9_BRANCH kra]$ git push Counting objects: 17, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (9/9), 976 bytes, done. Total 9 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/pki.git 98fed48..f103db3 DOGTAG_9_BRANCH -> DOGTAG_9_BRANCH JSS is to be in next build On 05/01/2012 03:11 PM, John Magne wrote: > ACK > > Patches address wrapping on Luna and improve error handling and logging. > > > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, May 1, 2012 8:42:47 AM > Subject: [Pki-devel] patches for review - Bug 744207 - Key archival fails when KRA is configured with lunasa > > > Please review the following patches for Bug 744207 - Key archival fails when KRA is configured with lunasa: > > JSS: > https://bugzilla.redhat.com/attachment.cgi?id=581108&action=diff&context=patch&collapsed=&headers=1&format=raw > > DRM/KRA: > https://bugzilla.redhat.com/attachment.cgi?id=581109&action=diff&context=patch&collapsed=&headers=1&format=raw > > The JSS patch alone allows key archival (both RSA and ECC) to work with lunasa token > where the lunasa token has to be KE-capable. Work done specifically on the following model: > Model: Luna SA v5 w/ PED auth and CKE > Part No: 908-000093-001 > > The DRM/KRA patch are just some debugging to make recovery debugging easier with an addition of non-static salt. > The recovery is not working currently, failing with wrapping operation during PBE creation: > Bug 817423 - Key recovery fails when KRA is configured with lunasa > which will be fixed at a later time. > > To test these patches for key archival on the said model of lunasa, one must turn on the prototype mode for recovery. > > thanks, > Christina > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu May 3 14:26:22 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 03 May 2012 10:26:22 -0400 Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: References: Message-ID: <1336055183.2247.40.camel@aleeredhat.laptop> Some more initial feedback: 1. You create the method retrieveCert(CertRetrievalRequestData data) which is a POST method. This method is unnecessary and violates general Restful principles. That is - we should be using a GET method - which you have provided. The reason we created a POST method for the KeyResource is because we needed to pass in large data blobs as part of the request (a trans wrapped session key for example). Is there a scenario where we would want to return the Certificate given say, the certificate request or some other large blob? If not, we should remove these methods. 2. The same point for the retrieveProfile (and retrievProfile (spelling?)) methods. The ProfileRetrievalRequest object contains only the profileID. These methods and objects are superfluous and should be removed. The GET method is sufficient. 3. There are a bunch of places where things are ToDo -- please use TODO instead - as it shows up in eclipse as a task to be done. 4. There are a bunch of places where WebApplicationException is thrown - those should be replaced by CMSException with the appropriate response code. 5. CertificateData has serialNumber as a string. Isn't there a class we were using for serial numbers? 6. enrollCert() returns a CertRequestInfo object, which does not contain any reference to a certificate (if issued). How would the user determine the serial number/ url of the certificate given a request? It makes sense to put in fields for the certificate url and possibly also serial number in the CertRequestInfo object. 7. EnrollmentRequestData has field renewal - that should be replaced by a boolean isRenewal. 8. The KeyRequest and CertRequest code is so similar - it makes sense to look now into using inheritance to leverage this. Ade On Wed, 2012-05-02 at 20:05 -0400, John Magne wrote: > Revised patch as per the suggestions below: > > All the suggestions made sense and I implemented them as suggested. > Tests ran fine. > > Questions from below: > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > looks like the certsInChain may contain a null value if x509cert exists > in mCACerts but not the last element. Is that case possible? > > I could not see this scenario. What the code is doing is checking to see if > you are trying to get the cert chain of a cert that is already a member of the CA's > cert chain. In that case, the size of the array will be the size of the CA's cert chain. > If this is not the case, the size of the array will be that value plus one. > > 9. Could you try creating some certs with this common name "E*Corp, Inc." > and "E-Corp, Inc." and see if it can find an exact match. The > escapeFilter() should escape the '*'. > > I tried this after the fixes and was able to get an exact match on "E*Corp, Inc". > > > ----- Original Message ----- > From: "Endi Sukma Dewata" > To: pki-devel at redhat.com, "John Magne" > Sent: Tuesday, May 1, 2012 6:05:28 PM > Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch > > On 4/30/2012 1:53 PM, John Magne wrote: > > Provide CA EE Restful interface and test client. > > > > Tickets #144 and #145 > > Providing the following: > > > > 1. Simple EE restful interface for certificates, printing, listing and searching. > > 2. Simple EE restful interface for certificate enrollment requests. > > 3. Simple EE restful interface for profiles and profile properties. > > 4. Simple Test client to exercise the functionality. > > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > > 6. Provide simple restful implementations of new interfaces added. > > > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > > in the DRM restful area. > > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. > > Some feedback: > > 1. The CMSRestClient could be moved into > base/common/src/com/netscape/cms/servlet/csadmin, which can be used by > any clients including the test tools. > > 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can > merge these classes into CMSErrorInterceptor and place it in the same > package as CMSRestClient. The interceptor can be added in the > CMSRestClient, so the subclasses don't need to do that. > > 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be > more than 1, so the code could be simplified. > > 4. In CertDAO.getCertChainData() the certsInChain array is allocated > multiple times. It should be possible to use the loop to determine the > length first, then allocate the array just once after that. > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > looks like the certsInChain may contain a null value if x509cert exists > in mCACerts but not the last element. Is that case possible? > > 6. The CertSearchData.escapeValueRfc1779() probably can be moved into > LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into > LDAPUtil.escapeFilter(). > > 7. In CertSearchData.build*Filter() it's not necessary to use "this." > when calling other methods of the same object. It's possible to use the > fields directly too. > > 8. In CertSearchData.build*Filter() the values should be escaped to > avoid injection attack: > > filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + > ")"); > > 9. In CertSearchData.buildAVAFilter() the code does a double escape with > the escape DN method. I think it should use 2 different escape methods, > one for the DN and the other for the filter. So the code would look like > this: > > lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); > > Could you try creating some certs with this common name "E*Corp, Inc." > and "E-Corp, Inc." and see if it can find an exact match. The > escapeFilter() should escape the '*'. > > 10. There are some formatting issues and trailing whitespaces. > Auto-formatting probably will fix this. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu May 3 16:38:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 03 May 2012 11:38:30 -0500 Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: References: Message-ID: <4FA2B486.3060205@redhat.com> On 5/2/2012 7:05 PM, John Magne wrote: > Revised patch as per the suggestions below: > > All the suggestions made sense and I implemented them as suggested. > Tests ran fine. Thanks for the changes. > Questions from below: > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > looks like the certsInChain may contain a null value if x509cert exists > in mCACerts but not the last element. Is that case possible? > > I could not see this scenario. What the code is doing is checking to see if > you are trying to get the cert chain of a cert that is already a member of the CA's > cert chain. In that case, the size of the array will be the size of the CA's cert chain. > If this is not the case, the size of the array will be that value plus one. The code also moves the cert into the beginning of the array. Here's the scenario I was asking, suppose the cert chain is: c0 c1 c2 c3 c4 Suppose c4 is the cert being requested. The code will generate this result without any problem: c4 c0 c1 c2 c3 However, suppose the requested cert is c2. The code will move c2 to first and shift the rest back by one position: c2 c0 c1 null c3 c4 can't be moved into the result since there isn't enough space. If the scenario is possible, the code would include a null in the result and possibly generate an index-out-of-bound error when moving c4. If the scenario is not possible, the code could be optimized to check the requested cert only against the last cert in the CA chain. -- Endi S. Dewata From jmagne at redhat.com Thu May 3 18:29:24 2012 From: jmagne at redhat.com (John Magne) Date: Thu, 03 May 2012 14:29:24 -0400 (EDT) Subject: [Pki-devel] Fwd: [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch In-Reply-To: <0ec61e3a-9d61-4b85-82f3-c3e1d24882db@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: Actually provide the patch: ----- Forwarded Message ----- From: "John Magne" To: pki-devel at redhat.com Sent: Wednesday, April 25, 2012 6:50:38 PM Subject: [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch Simple patch to allow the PKIJNDI realm to handle multi-entry ACLs. Ticket #123 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch Type: text/x-patch Size: 2349 bytes Desc: not available URL: From alee at redhat.com Thu May 3 19:24:22 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 03 May 2012 15:24:22 -0400 Subject: [Pki-devel] Fwd: [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch In-Reply-To: References: Message-ID: <1336073063.2247.55.camel@aleeredhat.laptop> ACK On Thu, 2012-05-03 at 14:29 -0400, John Magne wrote: > Actually provide the patch: > > ----- Forwarded Message ----- > From: "John Magne" > To: pki-devel at redhat.com > Sent: Wednesday, April 25, 2012 6:50:38 PM > Subject: [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch > > > Simple patch to allow the PKIJNDI realm to handle multi-entry ACLs. > > Ticket #123 From edewata at redhat.com Fri May 4 19:43:00 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 04 May 2012 14:43:00 -0500 Subject: [Pki-devel] [PATCH] 57 Added classpath variable for JSS. Message-ID: <4FA43144.70403@redhat.com> The Eclipse classpath has been modified to use JSS_LIB variable to avoid hard-coding the path to jss4.jar. The variable needs to be specified in Preferences -> Java -> Build Path -> Classpath Variables with this value: * 32-bit: /usr/lib/jss * 64-bit: /usr/lib64/jss Ticket #171 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0057-Added-classpath-variable-for-JSS.patch Type: text/x-patch Size: 1647 bytes Desc: not available URL: From jmagne at redhat.com Sat May 5 01:26:24 2012 From: jmagne at redhat.com (John Magne) Date: Fri, 04 May 2012 21:26:24 -0400 (EDT) Subject: [Pki-devel] [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch In-Reply-To: <1336073063.2247.55.camel@aleeredhat.laptop> Message-ID: <2e39d67f-eb34-4c4b-9649-3b32393ed741@zmail15.collab.prod.int.phx2.redhat.com> Thanks,pushed to master. ----- Original Message ----- From: "Ade Lee" To: "John Magne" Cc: pki-devel at redhat.com Sent: Thursday, May 3, 2012 12:24:22 PM Subject: Re: Fwd: [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch ACK On Thu, 2012-05-03 at 14:29 -0400, John Magne wrote: > Actually provide the patch: > > ----- Forwarded Message ----- > From: "John Magne" > To: pki-devel at redhat.com > Sent: Wednesday, April 25, 2012 6:50:38 PM > Subject: [pki-devel][Patch] 0001-JNDI-realm-enhancement-to-handle-multiple-entry-ACLs.patch > > > Simple patch to allow the PKIJNDI realm to handle multi-entry ACLs. > > Ticket #123 From jmagne at redhat.com Sat May 5 01:29:26 2012 From: jmagne at redhat.com (John Magne) Date: Fri, 04 May 2012 21:29:26 -0400 (EDT) Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: <1336055183.2247.40.camel@aleeredhat.laptop> Message-ID: Attached is the full diff from the current state of master. Contains Endi's fixes as well as his concern about the certificate chain code. Contains alee's suggestions including the class refactoring involving the CertRequests vs the KeyRequests. ----- Original Message ----- From: "Ade Lee" To: "John Magne" Cc: "Endi Sukma Dewata" , pki-devel at redhat.com Sent: Thursday, May 3, 2012 7:26:22 AM Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch Some more initial feedback: 1. You create the method retrieveCert(CertRetrievalRequestData data) which is a POST method. This method is unnecessary and violates general Restful principles. That is - we should be using a GET method - which you have provided. The reason we created a POST method for the KeyResource is because we needed to pass in large data blobs as part of the request (a trans wrapped session key for example). Is there a scenario where we would want to return the Certificate given say, the certificate request or some other large blob? If not, we should remove these methods. 2. The same point for the retrieveProfile (and retrievProfile (spelling?)) methods. The ProfileRetrievalRequest object contains only the profileID. These methods and objects are superfluous and should be removed. The GET method is sufficient. 3. There are a bunch of places where things are ToDo -- please use TODO instead - as it shows up in eclipse as a task to be done. 4. There are a bunch of places where WebApplicationException is thrown - those should be replaced by CMSException with the appropriate response code. 5. CertificateData has serialNumber as a string. Isn't there a class we were using for serial numbers? 6. enrollCert() returns a CertRequestInfo object, which does not contain any reference to a certificate (if issued). How would the user determine the serial number/ url of the certificate given a request? It makes sense to put in fields for the certificate url and possibly also serial number in the CertRequestInfo object. 7. EnrollmentRequestData has field renewal - that should be replaced by a boolean isRenewal. 8. The KeyRequest and CertRequest code is so similar - it makes sense to look now into using inheritance to leverage this. Ade On Wed, 2012-05-02 at 20:05 -0400, John Magne wrote: > Revised patch as per the suggestions below: > > All the suggestions made sense and I implemented them as suggested. > Tests ran fine. > > Questions from below: > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > looks like the certsInChain may contain a null value if x509cert exists > in mCACerts but not the last element. Is that case possible? > > I could not see this scenario. What the code is doing is checking to see if > you are trying to get the cert chain of a cert that is already a member of the CA's > cert chain. In that case, the size of the array will be the size of the CA's cert chain. > If this is not the case, the size of the array will be that value plus one. > > 9. Could you try creating some certs with this common name "E*Corp, Inc." > and "E-Corp, Inc." and see if it can find an exact match. The > escapeFilter() should escape the '*'. > > I tried this after the fixes and was able to get an exact match on "E*Corp, Inc". > > > ----- Original Message ----- > From: "Endi Sukma Dewata" > To: pki-devel at redhat.com, "John Magne" > Sent: Tuesday, May 1, 2012 6:05:28 PM > Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch > > On 4/30/2012 1:53 PM, John Magne wrote: > > Provide CA EE Restful interface and test client. > > > > Tickets #144 and #145 > > Providing the following: > > > > 1. Simple EE restful interface for certificates, printing, listing and searching. > > 2. Simple EE restful interface for certificate enrollment requests. > > 3. Simple EE restful interface for profiles and profile properties. > > 4. Simple Test client to exercise the functionality. > > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > > 6. Provide simple restful implementations of new interfaces added. > > > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > > in the DRM restful area. > > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. > > Some feedback: > > 1. The CMSRestClient could be moved into > base/common/src/com/netscape/cms/servlet/csadmin, which can be used by > any clients including the test tools. > > 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can > merge these classes into CMSErrorInterceptor and place it in the same > package as CMSRestClient. The interceptor can be added in the > CMSRestClient, so the subclasses don't need to do that. > > 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be > more than 1, so the code could be simplified. > > 4. In CertDAO.getCertChainData() the certsInChain array is allocated > multiple times. It should be possible to use the loop to determine the > length first, then allocate the array just once after that. > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > looks like the certsInChain may contain a null value if x509cert exists > in mCACerts but not the last element. Is that case possible? > > 6. The CertSearchData.escapeValueRfc1779() probably can be moved into > LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into > LDAPUtil.escapeFilter(). > > 7. In CertSearchData.build*Filter() it's not necessary to use "this." > when calling other methods of the same object. It's possible to use the > fields directly too. > > 8. In CertSearchData.build*Filter() the values should be escaped to > avoid injection attack: > > filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + > ")"); > > 9. In CertSearchData.buildAVAFilter() the code does a double escape with > the escape DN method. I think it should use 2 different escape methods, > one for the DN and the other for the filter. So the code would look like > this: > > lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); > > Could you try creating some certs with this common name "E*Corp, Inc." > and "E-Corp, Inc." and see if it can find an exact match. The > escapeFilter() should escape the '*'. > > 10. There are some formatting issues and trailing whitespaces. > Auto-formatting probably will fix this. > > _______________________________________________ > 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: 0003-Provide-CA-EE-Restful-interface-and-test-client.patch Type: text/x-patch Size: 209701 bytes Desc: not available URL: From mharmsen at redhat.com Sat May 5 03:47:33 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 04 May 2012 20:47:33 -0700 Subject: [Pki-devel] [PATCH] PKI Deployment Framework Message-ID: <4FA4A2D5.70901@redhat.com> Please review and provide an ACK for the attached patch. This patch attempts to continue implementation of the PKI Deployment Framework based upon the revised filesystem layout documented here: * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS The following patch adds/corrects functionality of the existing PKI Deployment Framework including (but not limited to): * Massaged logic to comply with PKI subsystems running within a shared instance * Developed code to take advantage of a single shared NSS security database model * Completed the following two 'scriptlets': o Dogtag 10: Python 'slot_assignment.py' Installation Scriptlet (https://fedorahosted.org/pki/ticket/146) o Dogtag 10: Python 'security_databases.py' Installation Scriptlet (https://fedorahosted.org/pki/ticket/136) * Created several additional PKI deployment helper utilities. After being installed on a FRESH system, this code can be tested by running the following command-line examples (as 'root' or 'sudo'): * mkdir /tmp/pki * sudo pkispawn -s CA -p /tmp/pki -v --dry_run * sudo pkispawn -s CA -p /tmp/pki -v * sudo pkispawn -s CA -p /tmp/pki -u -v --dry_run * sudo pkispawn -s CA -p /tmp/pki -u -v * sudo pkidestroy -s CA -p /tmp/pki -v --dry_run * sudo pkidestroy -s CA -p /tmp/pki -v For the most part, this code ONLY affects the un-released 'pki-deploy' package, so check-in of these changes should not harm the existing source in any way. The exceptions to this are changes to the following three previously existing files: * base/ca/shared/conf/CS.cfg.in * base/ra/apache/conf/httpd.conf * base/tps/apache/conf/httpd.conf and the addition of the following new qqfour files to account for the eventual move to Tomcat 7: * base/ca/shared/conf/tomcat.conf * base/kra/shared/conf/tomcat.conf * base/ocsp/shared/conf/tomcat.conf * base/tks/shared/conf/tomcat.conf Thanks in advance, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PKI-Deployment-Scriptlets.patch Type: text/x-patch Size: 168611 bytes Desc: not available URL: From alee at redhat.com Mon May 7 15:23:30 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 07 May 2012 11:23:30 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0032-BZ-819111-non-existent-container breaks replication Message-ID: <1336404210.2247.80.camel@aleeredhat.laptop> We recently moved the replication user to ou=cmsuser, cn=config, rather than simply cn=config. This breaks replication to older users. Code has been added to the replication setup code to create the needed container on the master server if it does not exist. This is the fix for dogtag 10. A similar fix will be applied to dogtag 9. Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0032-BZ-819111-non-existent-container-ou-cmsusers-breaks-.patch Type: text/x-patch Size: 2162 bytes Desc: not available URL: From alee at redhat.com Mon May 7 15:59:59 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 07 May 2012 11:59:59 -0400 Subject: [Pki-devel] [PATCH] dogtag 9 - pki-vakwetu-0033-BZ-819111-non-existent-container breaks replication Message-ID: <1336406399.2247.82.camel@aleeredhat.laptop> Same fix as in 0032, but in different location as its dogtag 9. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0033-BZ-819111-non-existent-container-breaks-replication.patch Type: text/x-patch Size: 3026 bytes Desc: not available URL: From mharmsen at redhat.com Mon May 7 17:55:33 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 07 May 2012 10:55:33 -0700 Subject: [Pki-devel] [PATCH] pki-vakwetu-0032-BZ-819111-non-existent-container breaks replication In-Reply-To: <1336404210.2247.80.camel@aleeredhat.laptop> References: <1336404210.2247.80.camel@aleeredhat.laptop> Message-ID: <4FA80C95.10108@redhat.com> On 05/07/12 08:23, Ade Lee wrote: > We recently moved the replication user to ou=cmsuser, cn=config, rather > than simply cn=config. This breaks replication to older users. Code > has been added to the replication setup code to create the needed > container on the master server if it does not exist. > > This is the fix for dogtag 10. A similar fix will be applied to dogtag > 9. > > Please review, > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Mon May 7 17:56:34 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 07 May 2012 10:56:34 -0700 Subject: [Pki-devel] [PATCH] dogtag 9 - pki-vakwetu-0033-BZ-819111-non-existent-container breaks replication In-Reply-To: <1336406399.2247.82.camel@aleeredhat.laptop> References: <1336406399.2247.82.camel@aleeredhat.laptop> Message-ID: <4FA80CD2.8040107@redhat.com> On 05/07/12 08:59, Ade Lee wrote: ACK CAVEAT: The "version" will need to be bumped once this package is officially released. > Same fix as in 0032, but in different location as its dogtag 9. > Please review. > > Ade > > > > _______________________________________________ > 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 alee at redhat.com Mon May 7 18:01:44 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 07 May 2012 14:01:44 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0032-BZ-819111-non-existent-container breaks replication In-Reply-To: <4FA80C95.10108@redhat.com> References: <1336404210.2247.80.camel@aleeredhat.laptop> <4FA80C95.10108@redhat.com> Message-ID: <1336413705.2247.83.camel@aleeredhat.laptop> thanks, pushed to master On Mon, 2012-05-07 at 10:55 -0700, Matthew Harmsen wrote: > On 05/07/12 08:23, Ade Lee wrote: > > We recently moved the replication user to ou=cmsuser, cn=config, rather > > than simply cn=config. This breaks replication to older users. Code > > has been added to the replication setup code to create the needed > > container on the master server if it does not exist. > > > > This is the fix for dogtag 10. A similar fix will be applied to dogtag > > 9. > > > > Please review, > > Ade > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > ACK From alee at redhat.com Mon May 7 18:02:21 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 07 May 2012 14:02:21 -0400 Subject: [Pki-devel] [PATCH] dogtag 9 - pki-vakwetu-0033-BZ-819111-non-existent-container breaks replication In-Reply-To: <4FA80CD2.8040107@redhat.com> References: <1336406399.2247.82.camel@aleeredhat.laptop> <4FA80CD2.8040107@redhat.com> Message-ID: <1336413742.2247.84.camel@aleeredhat.laptop> Thanks. Pushed to dogtag 9 branch. On Mon, 2012-05-07 at 10:56 -0700, Matthew Harmsen wrote: > On 05/07/12 08:59, Ade Lee wrote: > ACK > > CAVEAT: The "version" will need to be bumped once this package is > officially released. > > Same fix as in 0032, but in different location as its dogtag 9. > > 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 Mon May 7 20:30:58 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 07 May 2012 16:30:58 -0400 Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: References: Message-ID: <1336422658.2247.93.camel@aleeredhat.laptop> 1. In CertResourceService, you throw InternalServerException(). Its not clear to me how this is different from CMSException (which takes as its default 500 - Internal Server error). Is InternalServerException superfluous then? 2. In CertResourceService, you throw CertNotFoundException in the case of EBaseException. This is too broad -- CertNotFoundException should be thrown only in the case of EDBRecordNotFoundException 3. In CertsResourceService, in searchCerts(data), we call dao.listCerts() with 0 for the maxResults and maxTime. This could lead to unbounded searches. We need to pass in some limits. Other than that, it looks pretty good! Ade On Fri, 2012-05-04 at 21:29 -0400, John Magne wrote: > Attached is the full diff from the current state of master. > > Contains Endi's fixes as well as his concern about the certificate > chain code. > > Contains alee's suggestions including the class refactoring > involving the CertRequests vs the KeyRequests. > > ----- Original Message ----- > From: "Ade Lee" > To: "John Magne" > Cc: "Endi Sukma Dewata" , pki-devel at redhat.com > Sent: Thursday, May 3, 2012 7:26:22 AM > Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch > > Some more initial feedback: > > 1. You create the method retrieveCert(CertRetrievalRequestData data) > which is a POST method. This method is unnecessary and violates general > Restful principles. That is - we should be using a GET method - which > you have provided. The reason we created a POST method for the > KeyResource is because we needed to pass in large data blobs as part of > the request (a trans wrapped session key for example). > > Is there a scenario where we would want to return the Certificate given > say, the certificate request or some other large blob? If not, we > should remove these methods. > > 2. The same point for the retrieveProfile (and retrievProfile > (spelling?)) methods. The ProfileRetrievalRequest object contains only > the profileID. These methods and objects are superfluous and should be > removed. The GET method is sufficient. > > 3. There are a bunch of places where things are ToDo -- please use TODO > instead - as it shows up in eclipse as a task to be done. > > 4. There are a bunch of places where WebApplicationException is thrown - > those should be replaced by CMSException with the appropriate response > code. > > 5. CertificateData has serialNumber as a string. Isn't there a class we > were using for serial numbers? > > 6. enrollCert() returns a CertRequestInfo object, which does not contain > any reference to a certificate (if issued). How would the user > determine the serial number/ url of the certificate given a request? It > makes sense to put in fields for the certificate url and possibly also > serial number in the CertRequestInfo object. > > 7. EnrollmentRequestData has field renewal - that should be replaced by > a boolean isRenewal. > > 8. The KeyRequest and CertRequest code is so similar - it makes sense to > look now into using inheritance to leverage this. > > Ade > > On Wed, 2012-05-02 at 20:05 -0400, John Magne wrote: > > Revised patch as per the suggestions below: > > > > All the suggestions made sense and I implemented them as suggested. > > Tests ran fine. > > > > Questions from below: > > > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > > looks like the certsInChain may contain a null value if x509cert exists > > in mCACerts but not the last element. Is that case possible? > > > > I could not see this scenario. What the code is doing is checking to see if > > you are trying to get the cert chain of a cert that is already a member of the CA's > > cert chain. In that case, the size of the array will be the size of the CA's cert chain. > > If this is not the case, the size of the array will be that value plus one. > > > > 9. Could you try creating some certs with this common name "E*Corp, Inc." > > and "E-Corp, Inc." and see if it can find an exact match. The > > escapeFilter() should escape the '*'. > > > > I tried this after the fixes and was able to get an exact match on "E*Corp, Inc". > > > > > > ----- Original Message ----- > > From: "Endi Sukma Dewata" > > To: pki-devel at redhat.com, "John Magne" > > Sent: Tuesday, May 1, 2012 6:05:28 PM > > Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch > > > > On 4/30/2012 1:53 PM, John Magne wrote: > > > Provide CA EE Restful interface and test client. > > > > > > Tickets #144 and #145 > > > Providing the following: > > > > > > 1. Simple EE restful interface for certificates, printing, listing and searching. > > > 2. Simple EE restful interface for certificate enrollment requests. > > > 3. Simple EE restful interface for profiles and profile properties. > > > 4. Simple Test client to exercise the functionality. > > > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > > > 6. Provide simple restful implementations of new interfaces added. > > > > > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > > > in the DRM restful area. > > > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. > > > > Some feedback: > > > > 1. The CMSRestClient could be moved into > > base/common/src/com/netscape/cms/servlet/csadmin, which can be used by > > any clients including the test tools. > > > > 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can > > merge these classes into CMSErrorInterceptor and place it in the same > > package as CMSRestClient. The interceptor can be added in the > > CMSRestClient, so the subclasses don't need to do that. > > > > 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be > > more than 1, so the code could be simplified. > > > > 4. In CertDAO.getCertChainData() the certsInChain array is allocated > > multiple times. It should be possible to use the loop to determine the > > length first, then allocate the array just once after that. > > > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > > looks like the certsInChain may contain a null value if x509cert exists > > in mCACerts but not the last element. Is that case possible? > > > > 6. The CertSearchData.escapeValueRfc1779() probably can be moved into > > LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into > > LDAPUtil.escapeFilter(). > > > > 7. In CertSearchData.build*Filter() it's not necessary to use "this." > > when calling other methods of the same object. It's possible to use the > > fields directly too. > > > > 8. In CertSearchData.build*Filter() the values should be escaped to > > avoid injection attack: > > > > filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + > > ")"); > > > > 9. In CertSearchData.buildAVAFilter() the code does a double escape with > > the escape DN method. I think it should use 2 different escape methods, > > one for the DN and the other for the filter. So the code would look like > > this: > > > > lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); > > > > Could you try creating some certs with this common name "E*Corp, Inc." > > and "E-Corp, Inc." and see if it can find an exact match. The > > escapeFilter() should escape the '*'. > > > > 10. There are some formatting issues and trailing whitespaces. > > Auto-formatting probably will fix this. > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > From jmagne at redhat.com Tue May 8 01:58:30 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 07 May 2012 21:58:30 -0400 (EDT) Subject: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch In-Reply-To: <1336422658.2247.93.camel@aleeredhat.laptop> Message-ID: <13d7a431-8dae-4c7f-a5cf-796575a65992@zmail15.collab.prod.int.phx2.redhat.com> Thanks. Pushed to master based on suggested changes. ----- Original Message ----- From: "Ade Lee" To: "John Magne" Cc: "Endi Sukma Dewata" , pki-devel at redhat.com Sent: Monday, May 7, 2012 1:30:58 PM Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch 1. In CertResourceService, you throw InternalServerException(). Its not clear to me how this is different from CMSException (which takes as its default 500 - Internal Server error). Is InternalServerException superfluous then? 2. In CertResourceService, you throw CertNotFoundException in the case of EBaseException. This is too broad -- CertNotFoundException should be thrown only in the case of EDBRecordNotFoundException 3. In CertsResourceService, in searchCerts(data), we call dao.listCerts() with 0 for the maxResults and maxTime. This could lead to unbounded searches. We need to pass in some limits. Other than that, it looks pretty good! Ade On Fri, 2012-05-04 at 21:29 -0400, John Magne wrote: > Attached is the full diff from the current state of master. > > Contains Endi's fixes as well as his concern about the certificate > chain code. > > Contains alee's suggestions including the class refactoring > involving the CertRequests vs the KeyRequests. > > ----- Original Message ----- > From: "Ade Lee" > To: "John Magne" > Cc: "Endi Sukma Dewata" , pki-devel at redhat.com > Sent: Thursday, May 3, 2012 7:26:22 AM > Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch > > Some more initial feedback: > > 1. You create the method retrieveCert(CertRetrievalRequestData data) > which is a POST method. This method is unnecessary and violates general > Restful principles. That is - we should be using a GET method - which > you have provided. The reason we created a POST method for the > KeyResource is because we needed to pass in large data blobs as part of > the request (a trans wrapped session key for example). > > Is there a scenario where we would want to return the Certificate given > say, the certificate request or some other large blob? If not, we > should remove these methods. > > 2. The same point for the retrieveProfile (and retrievProfile > (spelling?)) methods. The ProfileRetrievalRequest object contains only > the profileID. These methods and objects are superfluous and should be > removed. The GET method is sufficient. > > 3. There are a bunch of places where things are ToDo -- please use TODO > instead - as it shows up in eclipse as a task to be done. > > 4. There are a bunch of places where WebApplicationException is thrown - > those should be replaced by CMSException with the appropriate response > code. > > 5. CertificateData has serialNumber as a string. Isn't there a class we > were using for serial numbers? > > 6. enrollCert() returns a CertRequestInfo object, which does not contain > any reference to a certificate (if issued). How would the user > determine the serial number/ url of the certificate given a request? It > makes sense to put in fields for the certificate url and possibly also > serial number in the CertRequestInfo object. > > 7. EnrollmentRequestData has field renewal - that should be replaced by > a boolean isRenewal. > > 8. The KeyRequest and CertRequest code is so similar - it makes sense to > look now into using inheritance to leverage this. > > Ade > > On Wed, 2012-05-02 at 20:05 -0400, John Magne wrote: > > Revised patch as per the suggestions below: > > > > All the suggestions made sense and I implemented them as suggested. > > Tests ran fine. > > > > Questions from below: > > > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > > looks like the certsInChain may contain a null value if x509cert exists > > in mCACerts but not the last element. Is that case possible? > > > > I could not see this scenario. What the code is doing is checking to see if > > you are trying to get the cert chain of a cert that is already a member of the CA's > > cert chain. In that case, the size of the array will be the size of the CA's cert chain. > > If this is not the case, the size of the array will be that value plus one. > > > > 9. Could you try creating some certs with this common name "E*Corp, Inc." > > and "E-Corp, Inc." and see if it can find an exact match. The > > escapeFilter() should escape the '*'. > > > > I tried this after the fixes and was able to get an exact match on "E*Corp, Inc". > > > > > > ----- Original Message ----- > > From: "Endi Sukma Dewata" > > To: pki-devel at redhat.com, "John Magne" > > Sent: Tuesday, May 1, 2012 6:05:28 PM > > Subject: Re: [Pki-devel] 0001-Provide-CA-EE-Restful-interface-and-test-client.patch > > > > On 4/30/2012 1:53 PM, John Magne wrote: > > > Provide CA EE Restful interface and test client. > > > > > > Tickets #144 and #145 > > > Providing the following: > > > > > > 1. Simple EE restful interface for certificates, printing, listing and searching. > > > 2. Simple EE restful interface for certificate enrollment requests. > > > 3. Simple EE restful interface for profiles and profile properties. > > > 4. Simple Test client to exercise the functionality. > > > 5. Created restful client base class inherited by CARestClient and DRMRestClient. > > > 6. Provide simple restful implementations of new interfaces added. > > > > > > ToDO: Need some more refactoring to base classes for some of the new classes which are similar to classes > > > in the DRM restful area. > > > ToDO: Actual certificate enrollment code that will be refactored from existing ProfileSubmitServlet. > > > > Some feedback: > > > > 1. The CMSRestClient could be moved into > > base/common/src/com/netscape/cms/servlet/csadmin, which can be used by > > any clients including the test tools. > > > > 2. The CAErrorInterceptor is identical to DRMErrorInterceptor. We can > > merge these classes into CMSErrorInterceptor and place it in the same > > package as CMSRestClient. The interceptor can be added in the > > CMSRestClient, so the subclasses don't need to do that. > > > > 3. In CertsResourceService.createSearchFilter() the 'matches' cannot be > > more than 1, so the code could be simplified. > > > > 4. In CertDAO.getCertChainData() the certsInChain array is allocated > > multiple times. It should be possible to use the loop to determine the > > length first, then allocate the array just once after that. > > > > 5. Also in CertDAO.getCertChainData() after the initialization loop it > > looks like the certsInChain may contain a null value if x509cert exists > > in mCACerts but not the last element. Is that case possible? > > > > 6. The CertSearchData.escapeValueRfc1779() probably can be moved into > > LDAPUtil.escapeDN(). We can rename the existing LDAPUtil.escape() into > > LDAPUtil.escapeFilter(). > > > > 7. In CertSearchData.build*Filter() it's not necessary to use "this." > > when calling other methods of the same object. It's possible to use the > > fields directly too. > > > > 8. In CertSearchData.build*Filter() the values should be escaped to > > avoid injection attack: > > > > filter.append("(certRecordId>=" + LDAPUtil.escapeFilter(serialFrom) + > > ")"); > > > > 9. In CertSearchData.buildAVAFilter() the code does a double escape with > > the escape DN method. I think it should use 2 different escape methods, > > one for the DN and the other for the filter. So the code would look like > > this: > > > > lf.append(LDAPUtil.escapeFilter(LDAPUtil.escapeDN(param))); > > > > Could you try creating some certs with this common name "E*Corp, Inc." > > and "E-Corp, Inc." and see if it can find an exact match. The > > escapeFilter() should escape the '*'. > > > > 10. There are some formatting issues and trailing whitespaces. > > Auto-formatting probably will fix this. > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > From mharmsen at redhat.com Thu May 10 21:18:16 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 10 May 2012 14:18:16 -0700 Subject: [Pki-devel] Future availability of Jython 2.5 (and/or preferably Jython 2.7) in Fedora? Message-ID: <4FAC3098.1060508@redhat.com> Alexander, David, and John, I am a developer on the Dogtag project (see http://pki.fedoraproject.org/wiki/Dogtag) and am currently one of the engineers that are re-writing the installation/configuration framework in Python 2.7. Since a large part of Dogtag 10 is written in Java 1.7, we are currently using the existing "Jython 2.2" that exists in Fedora 16/17 as a bridge to a new Java configuration servlet (Python 2.7 --> Jython 2.2 --> Java 1.7). I have recently seen on the web that a project has been funded for the creation of Jython 2.7 (see http://en.wikipedia.org/wiki/Jython) which would allow us to potentially run our Python 2.7 installation/configuration code as a single Jython 2.7 process, instead. I am writing to you regarding the current availability of "Jython 2.2" in Fedora, and would like to inquire about the potential future availability of "Jython 2.7" in Fedora (or even "jython 2.5" since it at least contains the "logging" mechanism). Are any of you aware of any plans in Fedora to move from Jython 2.2 to Jython 2.7 once it becomes available? If so, would any of you be aware of any timeframe for adoption by Fedora? Thanks in advance, -- Matt P. S. - Please include "pki-devel at redhat.com" in any replies to this message. From jdennis at redhat.com Thu May 10 21:21:40 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 10 May 2012 17:21:40 -0400 Subject: [Pki-devel] Future availability of Jython 2.5 (and/or preferably Jython 2.7) in Fedora? In-Reply-To: <4FAC3098.1060508@redhat.com> References: <4FAC3098.1060508@redhat.com> Message-ID: <4FAC3164.1070706@redhat.com> Sorry, I don't know anything about Jython :-( -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From akurtako at redhat.com Thu May 10 21:38:37 2012 From: akurtako at redhat.com (Aleksandar Kurtakov) Date: Thu, 10 May 2012 17:38:37 -0400 (EDT) Subject: [Pki-devel] Future availability of Jython 2.5 (and/or preferably Jython 2.7) in Fedora? In-Reply-To: <4FAC3098.1060508@redhat.com> Message-ID: I guess I should answer as I'm the maintainer in Fedora. See inline. ----- Original Message ----- > From: "Matthew Harmsen" > To: akurtako at redhat.com, "David Malcolm" , jmatthew at redhat.com > Cc: pki-devel at redhat.com > Sent: Friday, May 11, 2012 12:18:16 AM > Subject: Future availability of Jython 2.5 (and/or preferably Jython 2.7) in Fedora? > > Alexander, David, and John, > > I am a developer on the Dogtag project (see > http://pki.fedoraproject.org/wiki/Dogtag) and am currently one of the > engineers that are re-writing the installation/configuration > framework > in Python 2.7. Since a large part of Dogtag 10 is written in Java > 1.7, > we are currently using the existing "Jython 2.2" that exists in > Fedora > 16/17 as a bridge to a new Java configuration servlet (Python 2.7 --> > Jython 2.2 --> Java 1.7). > > I have recently seen on the web that a project has been funded for > the > creation of Jython 2.7 (see http://en.wikipedia.org/wiki/Jython) > which > would allow us to potentially run our Python 2.7 > installation/configuration code as a single Jython 2.7 process, > instead. That's really cool it was stagnating for quite some time. > > I am writing to you regarding the current availability of "Jython > 2.2" > in Fedora, and would like to inquire about the potential future > availability of "Jython 2.7" in Fedora (or even "jython 2.5" since it > at > least contains the "logging" mechanism). > > Are any of you aware of any plans in Fedora to move from Jython 2.2 > to > Jython 2.7 once it becomes available? > > If so, would any of you be aware of any timeframe for adoption by > Fedora? Currently I maintain jython only because it's needed by eclipse-pydev and pydev is still at 2.2 level. Having said that I don't have time for both updating jython to 2.5+ and updating pydev to work with it. So if someone is ready to work on updating jython package I'll do my part and fix pydev. So it's all about someone helping - I'll push it as soon as someone updates it so Fedora 18 is a possibility and if it proves to be stable I wouldn't mind backporting it to Fedora 17 too. Regards, Alex > > Thanks in advance, > -- Matt > > P. S. - Please include "pki-devel at redhat.com" in any replies to this > message. > From mharmsen at redhat.com Fri May 11 00:02:06 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 10 May 2012 17:02:06 -0700 Subject: [Pki-devel] Request for better Dogtag 10 terminology . . . Message-ID: <4FAC56FE.7030704@redhat.com> *PROBLEM: * Dogtag 10 is currently being designed with a new filesystem layout for PKI instances and is currently looking for a more accurate and descriptive terminology for its *"[instance]"* notation and its re-definition of the term *"PKI Instance"*. (see http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#File_System_Directory_Layout_.28Proposed.29 and below for details) *BACKGROUND:* Prior to Dogtag 10, CA, KRA, OCSP, TKS (Tomcat5/Tomcat6), and RA, TPS (Apache 2.2) subsystems all consisted of an individual "named" instance of their web server. Each of these instances were often generically referred to as a*"PKI instance"*. For example, a CA, KRA, TKS, and TPS might have something similar to the following layout: * /var/lib/pki-ca * /var/lib/pki-kra * /var/lib/pki-tks * /var/lib/pki-tps where each *"PKI Instance"* (named pki-ca, pki-kra, pki-tks, and pki-tps) is a separate process each containing their own collection of stand-alone NSS security databases. With the pending release of Dogtag 10, the notion of a single *named "PKI Instance"* has been introduced which no longer corresponds to a single PKI subsystem, but rather to the following definition: * consists of at least one of the following web server instances: o one Tomcat 7 instance and/or o one Apache 2.4 instance * if a Tomcat 7 instance is being utilized, this process may contain the following PKI subsystem(s): o one CA, and/or o one KRA, and/or o one OCSP, and/or o one TKS * similarly, if an Apache 2.4 instance is being utilized, this process may contain the following PKI subsystem(s): o one RA, and/or o one TPS For example, a CA, KRA, TKS and TPS might have something similar to the following layout: * /var/lib/pki/[instance]/tomcat/ca * /var/lib/pki/[instance]/tomcat/kra * /var/lib/pki/[instance]/tomcat/tks * /var/lib/pki/[instance]/apache/tps where the *[instance]* notation is replaced by a *named "PKI Instance"* (e.g. - *'default'*): * /var/lib/pki/default/tomcat/ca * /var/lib/pki/default/tomcat/kra * /var/lib/pki/default/tomcat/tks * /var/lib/pki/default/apache/tps Within this *"PKI Instance"* named *'default'*, the CA, KRA, and TKS constitute a single instance of Tomcat, TPS constitutes a single instance of Apache, and all four PKI subsystems share a single common collection of NSS security databases on a *named "PKI Instance"* basis. Note that this design allows future deployments to be similar to currently existing deployments, by merely creating more than one *named "PKI Instance"* on a single system, which in turn allows for the continued existence of multiple types of the same PKI subsystems on a single host (e. g. - two CAs and a KRA). *REQUEST FOR SUGGESTIONS:* As initially stated, we would like to replace the *"[instance]"* notation and *"PKI instance"* terminology currently used within Dogtag 10 with something that is more descriptive and more accurate. While several alternatives have already been suggested, none have gained wide-spread acceptance: * cluster (concerns about other non-PKI uses of this term) * domain (potential confusion with the notion of PKI security domain) * realm (potential conflict with the Tomcat concept) * crypt (a "play" on words which humorously attempts to describe these PKI subsystems as a collection of cryptographic services) * collection (concerns about other non-PKI uses of this term) * group (potentially over-used term) * bucket * family * pod In any event, whatever this terminology turns out to be, a *"PKI Instance" *will still need to be implemented as a "named" entity (e. g. - *'default'*). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Fri May 11 01:38:19 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 10 May 2012 21:38:19 -0400 Subject: [Pki-devel] Request for better Dogtag 10 terminology . . . In-Reply-To: <4FAC56FE.7030704@redhat.com> References: <4FAC56FE.7030704@redhat.com> Message-ID: <4FAC6D8B.1020709@redhat.com> On 05/10/2012 08:02 PM, Matthew Harmsen wrote: > As initially stated, we would like to replace the *"[instance]"* > notation and *"PKI instance"* terminology currently used within > Dogtag 10 with something that is more descriptive and more accurate. > While several alternatives have already been suggested, none have > gained wide-spread acceptance: Actually I think the term "instance" is descriptive and accurate, it makes perfect sense to me in the context of how it's being used. Terms like cluster, domain, realm, group, etc. have so many other connotations I think it would be more confusing because it implies something it's not. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kchamart at redhat.com Fri May 11 07:55:08 2012 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 11 May 2012 13:25:08 +0530 Subject: [Pki-devel] Request for better Dogtag 10 terminology . . . In-Reply-To: <4FAC6D8B.1020709@redhat.com> References: <4FAC56FE.7030704@redhat.com> <4FAC6D8B.1020709@redhat.com> Message-ID: <4FACC5DC.6090603@redhat.com> On 05/11/2012 07:08 AM, John Dennis wrote: > On 05/10/2012 08:02 PM, Matthew Harmsen wrote: >> As initially stated, we would like to replace the *"[instance]"* >> notation and *"PKI instance"* terminology currently used within >> Dogtag 10 with something that is more descriptive and more accurate. >> While several alternatives have already been suggested, none have >> gained wide-spread acceptance: > > Actually I think the term "instance" is descriptive and accurate, it makes perfect sense > to me in the context of how it's being used. Agreed. Terms like cluster, domain, realm, group, > etc. have so many other connotations I think it would be more confusing because it implies > something it's not. True, from a QE perspective, it's easier to refer it as pki(ca, etc,) instance while communicating to debug an issue. Also, the terms you mentioned are really over used in general, and in other projects. Not to mention, the word realm also being used in kerberos, 'group' being a standard *nix term, domain(again, a very vague term). > -- /kashyap From alee at redhat.com Fri May 11 15:02:23 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 11 May 2012 11:02:23 -0400 Subject: [Pki-devel] Request for better Dogtag 10 terminology . . . In-Reply-To: <4FACC5DC.6090603@redhat.com> References: <4FAC56FE.7030704@redhat.com> <4FAC6D8B.1020709@redhat.com> <4FACC5DC.6090603@redhat.com> Message-ID: <1336748543.2247.147.camel@aleeredhat.laptop> The term "instance" makes sense in this context when we are talking specifically about either a single tomcat or a single apache instance, even if that instance happens to correspond to multiple subsystems. And this would make sense, because all of the subsystems within that instance would be started/stopped by a single init script, and they will share things like a password.conf file and a common nss database. In the proposed layout though, we have the possibility of the "instance" containing both an apache and a tomcat instance - and hence the casting around for a new name. Unless we plan on writing some hybrid init script, that allows us to start/stop both apache and tomcat instances at the same time (which is very unlikely in the near future - and probably a bad idea in any case), maybe we should not allow the "instance" to contain both apache and tomcat instances. Instead I suggest the following : /var/lib/pki/tomcat0 (for the ca, kra, ocsp, tks) /var/lib/pki/apache0 (for the ra, tps) I think I like tomcat0 and apache0 rather than "default" - it makes it clearer that this is an instance name and also the type of instance. Ade On Fri, 2012-05-11 at 13:25 +0530, Kashyap Chamarthy wrote: > On 05/11/2012 07:08 AM, John Dennis wrote: > > On 05/10/2012 08:02 PM, Matthew Harmsen wrote: > >> As initially stated, we would like to replace the *"[instance]"* > >> notation and *"PKI instance"* terminology currently used within > >> Dogtag 10 with something that is more descriptive and more accurate. > >> While several alternatives have already been suggested, none have > >> gained wide-spread acceptance: > > > > Actually I think the term "instance" is descriptive and accurate, it makes perfect sense > > to me in the context of how it's being used. > > Agreed. > > Terms like cluster, domain, realm, group, > > etc. have so many other connotations I think it would be more confusing because it implies > > something it's not. > > True, from a QE perspective, it's easier to refer it as pki(ca, etc,) instance while > communicating to debug an issue. Also, the terms you mentioned are really over used in > general, and in other projects. Not to mention, the word realm also being used in > kerberos, 'group' being a standard *nix term, domain(again, a very vague term). > > > > > From edewata at redhat.com Mon May 14 20:08:48 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 14 May 2012 15:08:48 -0500 Subject: [Pki-devel] [PATCH] 58 Fixed missing httpcore.jar. Message-ID: <4FB16650.40801@redhat.com> The base/common/src/CMakeLists.txt has been fixed to include httpcore.jar in the class path. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0058-Fixed-missing-httpcore.jar.patch Type: text/x-patch Size: 1508 bytes Desc: not available URL: From mharmsen at redhat.com Fri May 18 18:05:01 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 18 May 2012 11:05:01 -0700 Subject: [Pki-devel] [PATCH] PKI Deployment Framework (20120518) Message-ID: <4FB68F4D.2010309@redhat.com> This patch documents continued implementation of the PKI Deployment Framework based upon the revised filesystem layout documented here: * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS The following patch adds/corrects functionality of the existing PKI Deployment Framework including (but not limited to): * Introduced concept of "admin-domain" originally as a separate folder, and later incorporated this concept into an optional instance prefix * Revised definition of to be identified as "[-] * Changed NSS security database model from one shared database by BOTH a single Tomcat AND single Apache instance into one per Tomcat instance (shared by CA/KRA/OCSP/TKS) and one per Apache instance (shared by RA/TPS) * Altered Configuration 'scriptlet' to invoke Jython for access to new Java configuration servlet * Renamed various "scriptlets" to comply with this new layout * Re-aligned code to account for revised layout documented at http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PKI-Deployment-Scriptlets-20120518.patch Type: text/x-patch Size: 118796 bytes Desc: not available URL: From akoneru at redhat.com Fri May 18 22:16:55 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 18 May 2012 18:16:55 -0400 Subject: [Pki-devel] Patches of Fixes for Coverity Issues for DogTag10 for Review Message-ID: <1337379415.15064.4.camel@abhishek> Hello Everyone, PFA review the pathches for fixes done for some of the Coverity Issues for DogTag 10. Thank you. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0001-Fixes-for-Coverity-Defects-of-Category-FB.BC_VACUOUS.patch Type: text/x-patch Size: 8576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0002-Fixes-for-Coverity-Defects-of-Category-FB.DM_BOOLEAN.patch Type: text/x-patch Size: 28733 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0003-Fixes-for-Coverity-Defects-of-Category-FB.DM_NUMBER_.patch Type: text/x-patch Size: 22366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0004-Fixes-for-Coverity-Defects-of-Category-FB.SBSC_USE_S.patch Type: text/x-patch Size: 78565 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0005-Fixes-for-Coverity-Defects-of-Category-FB.SBSC_USE_S.patch Type: text/x-patch Size: 23895 bytes Desc: not available URL: From edewata at redhat.com Fri May 18 23:54:51 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 18 May 2012 18:54:51 -0500 Subject: [Pki-devel] [PATCH] 57 Added classpath variable for JSS. In-Reply-To: <4FA43144.70403@redhat.com> References: <4FA43144.70403@redhat.com> Message-ID: <4FB6E14B.6050903@redhat.com> On 5/4/2012 2:43 PM, Endi Sukma Dewata wrote: > The Eclipse classpath has been modified to use JSS_LIB variable > to avoid hard-coding the path to jss4.jar. The variable needs to > be specified in Preferences -> Java -> Build Path -> Classpath > Variables with this value: > > * 32-bit: /usr/lib/jss > * 64-bit: /usr/lib64/jss > > Ticket #171 Revised the patch to create a link to the JSS library. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0057-2-Added-script-to-link-JSS-library.patch Type: text/x-patch Size: 3195 bytes Desc: not available URL: From edewata at redhat.com Mon May 21 15:25:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 21 May 2012 10:25:30 -0500 Subject: [Pki-devel] [PATCH] 59 Refactored audit service. Message-ID: <4FBA5E6A.2040607@redhat.com> Previously the audit service was only available to subclasses of AdminServlet. This functionality has been moved into a more generic Auditor service which can be used by others including REST services. In the future the AdminServlet should be modified to use the Auditor service. Ticket #160 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0059-Refactored-audit-service.patch Type: text/x-patch Size: 17080 bytes Desc: not available URL: From edewata at redhat.com Mon May 21 15:28:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 21 May 2012 10:28:56 -0500 Subject: [Pki-devel] [PATCH] 60 Added user REST service. Message-ID: <4FBA5F38.70503@redhat.com> The user REST service provides an interface to manage users and user certificates. It is based on UsrGrpAdminServlet. Ticket #160 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0060-Added-user-REST-service.patch Type: text/x-patch Size: 73184 bytes Desc: not available URL: From edewata at redhat.com Mon May 21 15:37:35 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 21 May 2012 10:37:35 -0500 Subject: [Pki-devel] [PATCH] 61 Added user CLI. Message-ID: <4FBA613F.3090301@redhat.com> The user CLI provides a tool to manage users and user certificates. Ticket #160 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0061-Added-user-CLI.patch Type: text/x-patch Size: 64972 bytes Desc: not available URL: From alee at redhat.com Mon May 21 15:39:32 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 21 May 2012 11:39:32 -0400 Subject: [Pki-devel] Patches of Fixes for Coverity Issues for DogTag10 for Review In-Reply-To: <1337379415.15064.4.camel@abhishek> References: <1337379415.15064.4.camel@abhishek> Message-ID: <1337614773.27239.38.camel@aleeredhat.laptop> Abhishek, Some comments. In general, when changing some lines of code, please fix formatting and indentation,remove extra blank lines etc. Patch 1: SimpleProperties.java - remove extra blank lines LdapRequestListener.java - fix indentation, remove extra blank line GenericPolicyProcessor.java - extra blank line ExtDataHashtable.java - formatting, also this can be simplified further. There is no need for the assignment of oKey to key. CMSProperties.java - extra lines Patch 2: ArgBlock.java - this is incorrect. You still need to create a boolean object. It should be: return mArgs.put(n, Boolean.valueOf(v)); PKIJNDIRealm.java - same comment here. Should be: v.addElement(Boolean.valueOf(passed)); in all three cases. SSLSelfSignedCert.java - change the one that is commented out too. BasicConstraintsExtension.java - same problem here. should be : return (Boolean.valueOf(ca)); CRLExtensions.java -same problem here. CertificateExtensions.java - same problem here. Extensions.java - and here KeyUsageExtension.java - and here ReasonFlags.java - and here Patch 3: SimpleProperties.java -- formatting. Should be : line = loppedLine + nextLine; EmailTemplate.java -- formatting and extra line TestClient.java - this is a pretty dumb function. Find all instances where this getString() function is called and replace with String.valueOf(foo) and remove this function. ExtendedKeyUsageExtension - this is very confusing. 1. there is no reason to use StringBuffer for presentation. 2. You can just initialize extByteValue in a single step: StringBuffer extByteValue = new StringBuffer(" val="); 3. Remove the commented out lines. OCSPNoCheckExtension.java - same kinds of comments as above. Patch 4 and 5: For these patches, I will make some general comments. Please check that all of these are addressed and resubmit. 1. avoid unneeded initializations: StringBuffer tempBuffer=new StringBuffer(); tempBuffer.append(""); <-- this line not needed 2. Initialize in a single step if possible. That is - StringBuffer foo = new StringBuffer("bar"); 3. If you change a line, remove it rather than commenting out. 4. Avoid unnecessary complication: tempBuffer.append("(").append(CertRecord.ATTR_META_INFO).append("=profileId:").append(id).append(")"); can be written as: tempBuffer.append("(" + CertRecord.ATTR_META_INFO + "=profileId:" + id + ")"; 5. Formatting: entry .append( ","); is bad entry.append(","); is better -- Note, removal of space in two places. Please fix all the above and resubmit. Also, please run the smoke test as well. Thanks, Ade On Fri, 2012-05-18 at 18:16 -0400, Abhishek Koneru wrote: > Hello Everyone, > > PFA review the pathches for fixes done for some of the Coverity > Issues for DogTag 10. > > Thank you. > Regards, > Abhishek Koneru > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon May 21 15:40:19 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 21 May 2012 10:40:19 -0500 Subject: [Pki-devel] [PATCH] 62 Added group REST service. Message-ID: <4FBA61E3.6030108@redhat.com> The group REST service provides an interface to manage groups and group members. It is based on UsrGrpAdminServlet. Ticket #160 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0062-Added-group-REST-service.patch Type: text/x-patch Size: 47131 bytes Desc: not available URL: From edewata at redhat.com Mon May 21 15:41:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 21 May 2012 10:41:41 -0500 Subject: [Pki-devel] [PATCH] 63 Added group CLI. Message-ID: <4FBA6235.5080109@redhat.com> This patch provides a tool to manage groups and group members via command line. Ticket #160 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0063-Added-group-CLI.patch Type: text/x-patch Size: 31642 bytes Desc: not available URL: From akoneru at redhat.com Wed May 23 22:09:22 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 23 May 2012 18:09:22 -0400 Subject: [Pki-devel] [Patch] Fixes for review comments given for Patches 1-5 for Coverity issues for DogTag10 Message-ID: <1337810962.1953.2.camel@abhishek> Hello Everyone, Please find attached the patch which contains the fixes for the review comments given for previous patches [1-5]. Smoke Test passed. Thank you. Regards, Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0006-Patch-for-fixes-for-Review-Comments.patch Type: text/x-patch Size: 41099 bytes Desc: not available URL: From mharmsen at redhat.com Thu May 24 02:09:54 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 23 May 2012 19:09:54 -0700 Subject: [Pki-devel] [PATCH] PKI Deployment Framework (20120523) Message-ID: <4FBD9872.6070208@redhat.com> This patch documents continued implementation of the PKI Deployment Framework based upon the revised filesystem layout documented here: * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS The following patch adds/corrects functionality of the existing PKI Deployment Framework including (but not limited to): * Integration of Tomcat 7 * Addition of centralized 'pki-tomcatd' systemd functionality to the PKI Deployment strategy * Removal of 'pki_flavor' attribute -- Matt P. S. - I still need to perform a couple of tests to make certain that this patch does not disrupt "pkicreate" installation/configuration prior to checking this in. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PKI-Deployment-Scriptlets-20120523.patch Type: text/x-patch Size: 172491 bytes Desc: not available URL: From alee at redhat.com Thu May 24 04:07:26 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 24 May 2012 00:07:26 -0400 Subject: [Pki-devel] [PATCH] 59 Refactored audit service. In-Reply-To: <4FBA5E6A.2040607@redhat.com> References: <4FBA5E6A.2040607@redhat.com> Message-ID: <1337832447.4525.54.camel@aleeredhat.laptop> As mentioned on #irc, the audit() functions in Auditor are too specific to auditing in the User / Group servlets. It will be difficult to provide any set of parameters that will cover all cases, so it may be easiest for now to do what the AdminServlet audit(String msg) function does -- which is take in a single String argument. The location of the class is also not the best. If nothing else, I would put it under com.netscape.certsrv.logging as this is where all the other classes handling auditing functions reside. The javadoc comments on each of the methods also need to be changed -- they talk about extended admin servlets. Also, it might be nice to go ahead and change admin servlet right now to use the new class. This will involve a little more testing -- using some of the existing servlets and confirming that the audit log messages are being written - but it will prevent code duplication. We will need to use this Auditor class in the other servlets we are replacing. Ade On Mon, 2012-05-21 at 10:25 -0500, Endi Sukma Dewata wrote: > Previously the audit service was only available to subclasses of > AdminServlet. This functionality has been moved into a more generic > Auditor service which can be used by others including REST services. In > the future the AdminServlet should be modified to use the Auditor service. > > Ticket #160 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu May 24 05:01:59 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 24 May 2012 01:01:59 -0400 Subject: [Pki-devel] [PATCH] 57 Added classpath variable for JSS. In-Reply-To: <4FB6E14B.6050903@redhat.com> References: <4FA43144.70403@redhat.com> <4FB6E14B.6050903@redhat.com> Message-ID: <1337835719.4525.55.camel@aleeredhat.laptop> ACK On Fri, 2012-05-18 at 18:54 -0500, Endi Sukma Dewata wrote: > On 5/4/2012 2:43 PM, Endi Sukma Dewata wrote: > > The Eclipse classpath has been modified to use JSS_LIB variable > > to avoid hard-coding the path to jss4.jar. The variable needs to > > be specified in Preferences -> Java -> Build Path -> Classpath > > Variables with this value: > > > > * 32-bit: /usr/lib/jss > > * 64-bit: /usr/lib64/jss > > > > Ticket #171 > > Revised the patch to create a link to the JSS library. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu May 24 17:13:20 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 24 May 2012 12:13:20 -0500 Subject: [Pki-devel] [PATCH] 57 Added classpath variable for JSS. In-Reply-To: <1337835719.4525.55.camel@aleeredhat.laptop> References: <4FA43144.70403@redhat.com> <4FB6E14B.6050903@redhat.com> <1337835719.4525.55.camel@aleeredhat.laptop> Message-ID: <4FBE6C30.5090605@redhat.com> On 5/24/2012 12:01 AM, Ade Lee wrote: > ACK Pushed to master. -- Endi S. Dewata From alee at redhat.com Thu May 24 19:00:33 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 24 May 2012 15:00:33 -0400 Subject: [Pki-devel] [PATCH] 60 Added user REST service. In-Reply-To: <4FBA5F38.70503@redhat.com> References: <4FBA5F38.70503@redhat.com> Message-ID: <1337886033.4525.101.camel@aleeredhat.laptop> Endi. Comments: 1. First of all, the location of the new classes. Earlier in the project, we made the decision to integrate the new RESTful classes within the existing servlet structure. This is why the Profile RESTful classes show up under com.netscape.cms.servlet.profile and the requests (key and cert) show up under com.netscape.cms.servlet.request. In this case, if we are following the existing structure and being consistent with the other RESTful servlets, we expect the REST servlets for users and groups to show up where the UsrGroupAdminServlet resides - which is under - com.netscape.cms.servlet.admin (like the SystemCertificateResource) Along the same lines, the JAXB and DAO classes should reside under com.netscape.cms.servlet.admin.model. After looking at the package layout doc, it appears that both your structure and the structure of the other new servlets is wrong. Rather, in this particular case, the interfaces (UserResource.java and UserCertResource.java as well as the JAXB classes UserData.java et. al. should reside under com.netscape.certsrv.usrgrp The UserCertResourceService and UserResourceService classes should reside under com.netscape.cms.servlet.admin CLI should go under com.netscape.cmstools 2. I like the use of the atom link. Please open a task to replace the Links in the other restful services. 3. The valueOf() function in UserData is incorrect. Should return UserData. 4. The getUserMessage() functions are perhaps not needed. If anything, they should be written as a single vargs method. But a better way to do this would be to specify locale the local as a protected variable in CMSResourceService.java. Then getLocale() would return this variable if it is non-null, or would find it from the headers. Then you can call the regular CMS.getUserMessage(locale, ....) without the getUserMessage() calls. Its important we do it this way because when we are writing RESTful servlets for things like cert issuance and revocation, we want to try to reduce code duplication as much as possible. 5. Similar considerations exist for the audit() functions. We want to use existing functions so that code can be extracted and reused by both restful and restful servlets. 6. Right now, the Delete user operation fails if the user is part of any groups. As discussed on #irc, we should create a resource at /users/{id}/groups for the client to check for group membership. And then allow the DELETE to remove users from groups automatically. 7. The paging mechanism in findUser() is not really the best - in that you basically get all of the results back from ldap each time. We really need paged searches instead. Its unlikely that this will be big concern for users/groups - but we should add a task to do proper paging. 8. The code in stripBrackets() and getEncodedCert() are used in many places in the code. After your changes, do all these still work? Ade On Mon, 2012-05-21 at 10:28 -0500, Endi Sukma Dewata wrote: > The user REST service provides an interface to manage users and user > certificates. It is based on UsrGrpAdminServlet. > > Ticket #160 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri May 25 03:11:09 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 24 May 2012 23:11:09 -0400 Subject: [Pki-devel] [Patch] Fixes for review comments given for Patches 1-5 for Coverity issues for DogTag10 In-Reply-To: <1337810962.1953.2.camel@abhishek> References: <1337810962.1953.2.camel@abhishek> Message-ID: <1337915470.4525.104.camel@aleeredhat.laptop> ACK. Pushed to master. On Wed, 2012-05-23 at 18:09 -0400, Abhishek Koneru wrote: > Hello Everyone, > > Please find attached the patch which contains the fixes for the > review comments given for previous patches [1-5]. > Smoke Test passed. > > Thank you. > Regards, > Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Fri May 25 18:27:26 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 25 May 2012 14:27:26 -0400 Subject: [Pki-devel] [PATCH] Fixes for Coverity Issues in categories : CALL_SUPER, UNCONFIRMEDCAST, DEAD_STORE, TOSTRING_ARRAY Message-ID: <1337970446.25022.3.camel@abhishek> Please find attached the patch with fixes for some of the coverity issues for review. Thanks & Regards, Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0007-Fixes-for-Coverity-Issues-CALL_SUPER-UNCONFIRMEDCAST.patch Type: text/x-patch Size: 19232 bytes Desc: not available URL: From cfu at redhat.com Fri May 25 20:45:15 2012 From: cfu at redhat.com (Christina Fu) Date: Fri, 25 May 2012 13:45:15 -0700 Subject: [Pki-devel] Patch for review: Bug 823618 - TPS installation wizard (ECC): admin certificate panel needs to support ECC Message-ID: <4FBFEF5B.8010008@redhat.com> Please review the patch for the following bug: *Bug 823618* -TPS installation wizard (ECC): admin certificate panel needs to support ECC https://bugzilla.redhat.com/attachment.cgi?id=586949&action=diff&context=patch&collapsed=&headers=1&format=raw thanks, Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Fri May 25 20:59:37 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 May 2012 15:59:37 -0500 Subject: [Pki-devel] [PATCH] 59 Refactored audit service. In-Reply-To: <1337832447.4525.54.camel@aleeredhat.laptop> References: <4FBA5E6A.2040607@redhat.com> <1337832447.4525.54.camel@aleeredhat.laptop> Message-ID: <4FBFF2B9.1070204@redhat.com> New patch attached. On 5/23/2012 11:07 PM, Ade Lee wrote: > As mentioned on #irc, the audit() functions in Auditor are too specific > to auditing in the User / Group servlets. It will be difficult to > provide any set of parameters that will cover all cases, so it may be > easiest for now to do what the AdminServlet audit(String msg) function > does -- which is take in a single String argument. Fixed. > The location of the class is also not the best. If nothing else, I > would put it under com.netscape.certsrv.logging as this is where all the > other classes handling auditing functions reside. I put the IAuditor in certsrv.logging and Auditor in cmscore.logging. > The javadoc comments on each of the methods also need to be changed -- > they talk about extended admin servlets. Fixed. > Also, it might be nice to go ahead and change admin servlet right now to > use the new class. This will involve a little more testing -- using > some of the existing servlets and confirming that the audit log messages > are being written - but it will prevent code duplication. I'll post a separate patch. > We will need to use this Auditor class in the other servlets we are > replacing. > > Ade -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0059-2-Added-Auditor-service.patch Type: text/x-patch Size: 18374 bytes Desc: not available URL: From edewata at redhat.com Fri May 25 21:02:09 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 25 May 2012 16:02:09 -0500 Subject: [Pki-devel] [PATCH] 64 Refactored AdminServlet. Message-ID: <4FBFF351.1050002@redhat.com> The AdminServlet has been modified to use the new Auditor service. Ticket #160 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0064-Refactored-AdminServlet.patch Type: text/x-patch Size: 11911 bytes Desc: not available URL: From awnuk at redhat.com Fri May 25 21:41:13 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Fri, 25 May 2012 14:41:13 -0700 Subject: [Pki-devel] Patch for review: Bug 823618 - TPS installation wizard (ECC): admin certificate panel needs to support ECC In-Reply-To: <4FBFEF5B.8010008@redhat.com> References: <4FBFEF5B.8010008@redhat.com> Message-ID: <4FBFFC79.2010200@redhat.com> On 05/25/2012 01:45 PM, Christina Fu wrote: > Please review the patch for the following bug: > *Bug 823618* -TPS > installation wizard (ECC): admin certificate panel needs to support ECC > > https://bugzilla.redhat.com/attachment.cgi?id=586949&action=diff&context=patch&collapsed=&headers=1&format=raw > > thanks, > Christina > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel This patch was tested by Christina. This patch also follows previously submitted and tested patch for java components. ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue May 29 14:32:59 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 29 May 2012 10:32:59 -0400 Subject: [Pki-devel] [PATCH] 64 Refactored AdminServlet. In-Reply-To: <4FBFF351.1050002@redhat.com> References: <4FBFF351.1050002@redhat.com> Message-ID: <1338301980.3069.0.camel@aleeredhat.laptop> ack On Fri, 2012-05-25 at 16:02 -0500, Endi Sukma Dewata wrote: > The AdminServlet has been modified to use the new Auditor service. > > Ticket #160 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue May 29 14:33:16 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 29 May 2012 10:33:16 -0400 Subject: [Pki-devel] [PATCH] 59 Refactored audit service. In-Reply-To: <4FBFF2B9.1070204@redhat.com> References: <4FBA5E6A.2040607@redhat.com> <1337832447.4525.54.camel@aleeredhat.laptop> <4FBFF2B9.1070204@redhat.com> Message-ID: <1338301997.3069.1.camel@aleeredhat.laptop> ack On Fri, 2012-05-25 at 15:59 -0500, Endi Sukma Dewata wrote: > New patch attached. > > On 5/23/2012 11:07 PM, Ade Lee wrote: > > As mentioned on #irc, the audit() functions in Auditor are too specific > > to auditing in the User / Group servlets. It will be difficult to > > provide any set of parameters that will cover all cases, so it may be > > easiest for now to do what the AdminServlet audit(String msg) function > > does -- which is take in a single String argument. > > Fixed. > > > The location of the class is also not the best. If nothing else, I > > would put it under com.netscape.certsrv.logging as this is where all the > > other classes handling auditing functions reside. > > I put the IAuditor in certsrv.logging and Auditor in cmscore.logging. > > > The javadoc comments on each of the methods also need to be changed -- > > they talk about extended admin servlets. > > Fixed. > > > Also, it might be nice to go ahead and change admin servlet right now to > > use the new class. This will involve a little more testing -- using > > some of the existing servlets and confirming that the audit log messages > > are being written - but it will prevent code duplication. > > I'll post a separate patch. > > > We will need to use this Auditor class in the other servlets we are > > replacing. > > > > Ade > > From alee at redhat.com Tue May 29 15:44:23 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 29 May 2012 11:44:23 -0400 Subject: [Pki-devel] [PATCH] Fixes for Coverity Issues in categories : CALL_SUPER, UNCONFIRMEDCAST, DEAD_STORE, TOSTRING_ARRAY In-Reply-To: <1337970446.25022.3.camel@abhishek> References: <1337970446.25022.3.camel@abhishek> Message-ID: <1338306264.3069.10.camel@aleeredhat.laptop> Comments: 1. The fix in Resender.java is not correct - that is replyRequestId.toString() is not the same as replymsg.reqId.substring(index + 1). There are some conversions that take place. I'm OK with reverting your fix here, and marking the bug as intentional/ignore. 2. In SelfTestSubsystem.java, remove the comments as well: // strip preceding/trailing whitespace // from passed-in String parameters 3. In CMCRevoke, no need to specify : String asciiBASE64Blob = null; You can just specify String asciiBASE64Blob; 4. In Request.java, you can specify StringBuffer s = con.getPage(); 5. In PKCS7.java, you need the new byte[] data = byte[len] in case dis.available() == 0 . I'm not sure I like the way this method is written. Lets revert the fix and leave this unfixed for now. 6. Can you explain to me why you think adding the Override tags will fix the call_super issues? Ade On Fri, 2012-05-25 at 14:27 -0400, Abhishek Koneru wrote: > Please find attached the patch with fixes for some of the coverity > issues for review. > > Thanks & Regards, > Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue May 29 21:37:35 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 29 May 2012 16:37:35 -0500 Subject: [Pki-devel] [PATCH] 60 Added user REST service. In-Reply-To: <1337886033.4525.101.camel@aleeredhat.laptop> References: <4FBA5F38.70503@redhat.com> <1337886033.4525.101.camel@aleeredhat.laptop> Message-ID: <4FC5419F.40502@redhat.com> New patch attached. On 5/24/2012 2:00 PM, Ade Lee wrote: > 1. First of all, the location of the new classes. Earlier in the > project, we made the decision to integrate the new RESTful classes > within the existing servlet structure. This is why the Profile RESTful > classes show up under com.netscape.cms.servlet.profile and the requests > (key and cert) show up under com.netscape.cms.servlet.request. The current packaging structure is no longer adequate for REST client and CLI. The packages are supposed to be reorganized later in ticket #114. As mentioned in the last meeting, I'm going to write a proposal about this on a wiki page. Here are the package names that I used in the original patch: - com.netscape.cms.user (common classes: REST interface & data model) - com.netscape.cms.user.client (client classes: REST client & CLI) - com.netscape.cms.user.server (server classes: REST services) After some more consideration, I tend to go with a slightly different structure which will be simpler to build and package into jar files: - com.netscape.cms.user - com.netscape.cms.client.user - com.netscape.cms.server.user > In this case, if we are following the existing structure and being > consistent with the other RESTful servlets, we expect the REST servlets > for users and groups to show up where the UsrGroupAdminServlet resides - > which is under - com.netscape.cms.servlet.admin (like the > SystemCertificateResource) This is OK except that the REST services aren't servlets even though they might be running inside the RESTEasy servlet. The REST services don't implement the Servlet interface and they don't follow servlet's life cycle. So having a "servlet" in the package name is inaccurate. I would suggest that we rename it to "server" because these classes (both REST services and servlets) are only used by the server. So the com.netscape.cms.servlet is actually identical with com.netscape.cms.server that I'm proposing. > Along the same lines, the JAXB and DAO classes should reside under > com.netscape.cms.servlet.admin.model. This would not be correct because the current "cms/servlet" package is intended for server only. The data model classes are used for data transfer, so they should be shared by both client and server. Right now we don't have a "common" package (the jar file, not the folder). The closest thing is "certsrv", but this package is intended to store server plugin interfaces which the client would never use. The "certsrv" might also have some dependencies that should not be required on the client side. > After looking at the package layout doc, it appears that both your > structure and the structure of the other new servlets is wrong. Rather, > in this particular case, the interfaces (UserResource.java and > UserCertResource.java as well as the JAXB classes UserData.java et. al. > should reside under com.netscape.certsrv.usrgrp Same as above, they should belong to the "common" package, but "certsrv" is the closest thing that's available now, so for now I'll put it there. > The UserCertResourceService and UserResourceService classes should > reside under com.netscape.cms.servlet.admin This is not a big issue, but "admin" package contains a mix of servlets, some of which are subsystem-specific. It would be better to put them in separate Java packages (e.g. cms.server.user) to simplify packaging. > CLI should go under com.netscape.cmstools This doesn't work because the REST interfaces and the data models are stored in "certsrv" or "cms", and the "cmstools" is compiled before them. So if we put the CLI in "cmstools" there will be a dependency issue. I couldn't put it in "certsrv" either because the CLI depends on the CMSRestClient which is in "cms" and the "certsrv" isn't suppose to depend on "cms". We could move CMSRestClient to "certsrv" too, but the CLI should really belong to a new "client" package. For now I'm going to leave the CLI in com.netscape.cms.client.user under the "cms" package. We can move this again if necessary in ticket #114. > 2. I like the use of the atom link. Please open a task to replace the > Links in the other restful services. The Atom links are now still created manually. We should utilize link injection. Ticket #192. > 3. The valueOf() function in UserData is incorrect. Should return > UserData. Fixed. > 4. The getUserMessage() functions are perhaps not needed. If anything, > they should be written as a single vargs method. Changed to use varargs. This method is used to simplify the code, compare: - old: CMS.getUserMessage(getLocale(), "CMS_ADMIN_SRVLT_NULL_RS_ID") - new: getUserMessage("CMS_ADMIN_SRVLT_NULL_RS_ID") > But a better way to do > this would be to specify locale the local as a protected variable in > CMSResourceService.java. Then getLocale() would return this variable if > it is non-null, or would find it from the headers. You mean caching the value returned by getLocale()? That can be done, but the "locale" variable will be null until we call getLocale() at least once. > Then you can call the regular CMS.getUserMessage(locale, ....) without > the getUserMessage() calls. For this to work we'd have to set the "locale" first, so we need to call getLocale() somewhere. I'm not sure if calling it in the CMSResourceService constructor will work because the "headers" is injected, which I suppose can only happen after the object is constructed. We can call it in the beginning of each REST method, but that's not pretty. So for now I'm keeping the getUserMessage(). > Its important we do it this way because when we are writing RESTful > servlets for things like cert issuance and revocation, we want to try to > reduce code duplication as much as possible. > > 5. Similar considerations exist for the audit() functions. We want to > use existing functions so that code can be extracted and reused by both > restful and restful servlets. It's been updated based on the new Auditor patch. > 6. Right now, the Delete user operation fails if the user is part of any > groups. As discussed on #irc, we should create a resource > at /users/{id}/groups for the client to check for group membership. And > then allow the DELETE to remove users from groups automatically. Fixed. The user-group membership will be done in ticket #190. > 7. The paging mechanism in findUser() is not really the best - in that > you basically get all of the results back from ldap each time. We > really need paged searches instead. Its unlikely that this will be big > concern for users/groups - but we should add a task to do proper paging. Right now it's using a very simple, maybe slower, but correct implementation. To do paging properly we will need VLV or simple paged results, which have their own limitations and possibly require sessions (not RESTful). The UGSubsystem doesn't seem to support paging either. How many users/groups do we need to be able to support? If its not large probably the current solution is adequate. > 8. The code in stripBrackets() and getEncodedCert() are used in many > places in the code. After your changes, do all these still work? As discussed on IRC, the change in getEncodedCert() fixes the extra blank line in certificates. The blank line got added when we change the Base64 encoder/decoder sometime ago, so it's now back to the correct behavior. The change in stripBrackets() has been removed. The UserCertResourceService now normalizes the cert first. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0060-2-Added-user-REST-service.patch Type: text/x-patch Size: 78601 bytes Desc: not available URL: From edewata at redhat.com Tue May 29 21:39:25 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 29 May 2012 16:39:25 -0500 Subject: [Pki-devel] [PATCH] 61 Added user CLI. In-Reply-To: <4FBA613F.3090301@redhat.com> References: <4FBA613F.3090301@redhat.com> Message-ID: <4FC5420D.3050708@redhat.com> On 5/21/2012 10:37 AM, Endi Sukma Dewata wrote: > The user CLI provides a tool to manage users and user certificates. > > Ticket #160 New patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0061-2-Added-user-CLI.patch Type: text/x-patch Size: 63350 bytes Desc: not available URL: From edewata at redhat.com Tue May 29 21:40:50 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 29 May 2012 16:40:50 -0500 Subject: [Pki-devel] [PATCH] 62 Added group REST service. In-Reply-To: <4FBA61E3.6030108@redhat.com> References: <4FBA61E3.6030108@redhat.com> Message-ID: <4FC54262.50906@redhat.com> On 5/21/2012 10:40 AM, Endi Sukma Dewata wrote: > The group REST service provides an interface to manage groups and group > members. It is based on UsrGrpAdminServlet. > > Ticket #160 New patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0062-2-Added-group-REST-service.patch Type: text/x-patch Size: 50817 bytes Desc: not available URL: From edewata at redhat.com Tue May 29 21:42:28 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 29 May 2012 16:42:28 -0500 Subject: [Pki-devel] [PATCH] 63 Added group CLI. In-Reply-To: <4FBA6235.5080109@redhat.com> References: <4FBA6235.5080109@redhat.com> Message-ID: <4FC542C4.4030109@redhat.com> On 5/21/2012 10:41 AM, Endi Sukma Dewata wrote: > This patch provides a tool to manage groups and group members via > command line. > > Ticket #160 New patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0063-2-Added-group-CLI.patch Type: text/x-patch Size: 35286 bytes Desc: not available URL: From awnuk at redhat.com Wed May 30 00:54:38 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 29 May 2012 17:54:38 -0700 Subject: [Pki-devel] PerLDAP patch Message-ID: <4FC56FCE.8080806@redhat.com> This is a work around for PerLDAP issue provided by Mark. Ticket #373. -------------- next part -------------- Index: pki/base/tps/lib/perl/PKI/TPS/Common.pm =================================================================== --- pki/base/tps/lib/perl/PKI/TPS/Common.pm (revision 2419) +++ pki/base/tps/lib/perl/PKI/TPS/Common.pm (working copy) @@ -65,9 +65,8 @@ foreach my $attr (@addtypes) { my @vals = $aentry->getValues($attr); - push @vals, $vals[0]; # HACK! for some reason, first value always fails with server unwilling to perform - - foreach my $val (@vals) { + my @values = ("dummyAttr: dummy value", @vals); # this dummy entry consumes the error 53 + foreach my $val (@values) { $sentry->addValue( $attr, $val ); $conn->update($sentry); my $rc = $conn->getErrorCode(); From nkinder at redhat.com Wed May 30 15:42:30 2012 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 30 May 2012 08:42:30 -0700 Subject: [Pki-devel] PerLDAP patch In-Reply-To: <4FC56FCE.8080806@redhat.com> References: <4FC56FCE.8080806@redhat.com> Message-ID: <4FC63FE6.5080604@redhat.com> ack On 05/29/2012 05:54 PM, Andrew Wnuk wrote: > This is a work around for PerLDAP issue provided by Mark. > > Ticket #373. > > > > > _______________________________________________ > 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 akoneru at redhat.com Wed May 30 19:09:30 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 30 May 2012 15:09:30 -0400 Subject: [Pki-devel] [PATCH] Fixes review comments on Patch Fixes for Coverity Issues in categories : CALL_SUPER, UNCONFIRMEDCAST, DEAD_STORE, TOSTRING_ARRAY In-Reply-To: <1338306264.3069.10.camel@aleeredhat.laptop> References: <1337970446.25022.3.camel@abhishek> <1338306264.3069.10.camel@aleeredhat.laptop> Message-ID: <1338404970.1790.2.camel@abhishek> Please find attached the patch which contains fixes for review comments given. Smoke Test Passes. Regards, Abhishek Koneru On Tue, 2012-05-29 at 11:44 -0400, Ade Lee wrote: > Comments: > > 1. The fix in Resender.java is not correct - that is > replyRequestId.toString() is not the same as > replymsg.reqId.substring(index + 1). There are some conversions that > take place. > > I'm OK with reverting your fix here, and marking the bug as > intentional/ignore. > > 2. In SelfTestSubsystem.java, remove the comments as well: > // strip preceding/trailing whitespace > // from passed-in String parameters > > 3. In CMCRevoke, no need to specify : String asciiBASE64Blob = null; > You can just specify String asciiBASE64Blob; > > 4. In Request.java, you can specify StringBuffer s = con.getPage(); > > 5. In PKCS7.java, you need the new byte[] data = byte[len] in case > dis.available() == 0 . I'm not sure I like the way this method is > written. Lets revert the fix and leave this unfixed for now. > > 6. Can you explain to me why you think adding the Override tags will fix > the call_super issues? > > Ade > > > On Fri, 2012-05-25 at 14:27 -0400, Abhishek Koneru wrote: > > Please find attached the patch with fixes for some of the coverity > > issues for review. > > > > Thanks & Regards, > > Abhishek > > _______________________________________________ > > 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-akoneru-0008-Patch-with-fixes-for-review-comments-0529.patch Type: text/x-patch Size: 5016 bytes Desc: not available URL: From alee at redhat.com Thu May 31 15:20:28 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 31 May 2012 11:20:28 -0400 Subject: [Pki-devel] [PATCH] 60 Added user REST service. In-Reply-To: <4FC5419F.40502@redhat.com> References: <4FBA5F38.70503@redhat.com> <1337886033.4525.101.camel@aleeredhat.laptop> <4FC5419F.40502@redhat.com> Message-ID: <1338477629.3069.39.camel@aleeredhat.laptop> On Tue, 2012-05-29 at 16:37 -0500, Endi Sukma Dewata wrote: > New patch attached. > > On 5/24/2012 2:00 PM, Ade Lee wrote: > > 1. First of all, the location of the new classes. Earlier in the > > project, we made the decision to integrate the new RESTful classes > > within the existing servlet structure. This is why the Profile RESTful > > classes show up under com.netscape.cms.servlet.profile and the requests > > (key and cert) show up under com.netscape.cms.servlet.request. > > The current packaging structure is no longer adequate for REST client > and CLI. The packages are supposed to be reorganized later in ticket > #114. As mentioned in the last meeting, I'm going to write a proposal > about this on a wiki page. > > Here are the package names that I used in the original patch: > - com.netscape.cms.user (common classes: REST interface & data model) > - com.netscape.cms.user.client (client classes: REST client & CLI) > - com.netscape.cms.user.server (server classes: REST services) > > After some more consideration, I tend to go with a slightly different > structure which will be simpler to build and package into jar files: > - com.netscape.cms.user > - com.netscape.cms.client.user > - com.netscape.cms.server.user > > > In this case, if we are following the existing structure and being > > consistent with the other RESTful servlets, we expect the REST servlets > > for users and groups to show up where the UsrGroupAdminServlet resides - > > which is under - com.netscape.cms.servlet.admin (like the > > SystemCertificateResource) > > This is OK except that the REST services aren't servlets even though > they might be running inside the RESTEasy servlet. The REST services > don't implement the Servlet interface and they don't follow servlet's > life cycle. So having a "servlet" in the package name is inaccurate. I > would suggest that we rename it to "server" because these classes (both > REST services and servlets) are only used by the server. So the > com.netscape.cms.servlet is actually identical with > com.netscape.cms.server that I'm proposing. > > > Along the same lines, the JAXB and DAO classes should reside under > > com.netscape.cms.servlet.admin.model. > > This would not be correct because the current "cms/servlet" package is > intended for server only. The data model classes are used for data > transfer, so they should be shared by both client and server. Right now > we don't have a "common" package (the jar file, not the folder). The > closest thing is "certsrv", but this package is intended to store server > plugin interfaces which the client would never use. The "certsrv" might > also have some dependencies that should not be required on the client side. > > > After looking at the package layout doc, it appears that both your > > structure and the structure of the other new servlets is wrong. Rather, > > in this particular case, the interfaces (UserResource.java and > > UserCertResource.java as well as the JAXB classes UserData.java et. al. > > should reside under com.netscape.certsrv.usrgrp > > Same as above, they should belong to the "common" package, but "certsrv" > is the closest thing that's available now, so for now I'll put it there. > > > The UserCertResourceService and UserResourceService classes should > > reside under com.netscape.cms.servlet.admin > > This is not a big issue, but "admin" package contains a mix of servlets, > some of which are subsystem-specific. It would be better to put them in > separate Java packages (e.g. cms.server.user) to simplify packaging. > We appear to have come full circle. When I originally created the first drm servlets, I put them under their own package separate from the old "servlets" because they did not follow the servlet lifecycle - other than going through the RESTEasy servlets. Based on review discussions, we decided then to move them to be integrated with the existing code structure. We need to rethink how all of this is packaged, keeping in mind some sort of continuity between the old and new interfaces so that it is easy to maintain. So, lets go ahead and check in for now, and then rearrange as makes sense once we have carefully considered the packaging. > > CLI should go under com.netscape.cmstools > > This doesn't work because the REST interfaces and the data models are > stored in "certsrv" or "cms", and the "cmstools" is compiled before > them. So if we put the CLI in "cmstools" there will be a dependency > issue. I couldn't put it in "certsrv" either because the CLI depends on > the CMSRestClient which is in "cms" and the "certsrv" isn't suppose to > depend on "cms". > > We could move CMSRestClient to "certsrv" too, but the CLI should really > belong to a new "client" package. For now I'm going to leave the CLI in > com.netscape.cms.client.user under the "cms" package. We can move this > again if necessary in ticket #114. agreed. > > 2. I like the use of the atom link. Please open a task to replace the > > Links in the other restful services. > > The Atom links are now still created manually. We should utilize link > injection. Ticket #192. > > > 3. The valueOf() function in UserData is incorrect. Should return > > UserData. > > Fixed. > > > 4. The getUserMessage() functions are perhaps not needed. If anything, > > they should be written as a single vargs method. > > Changed to use varargs. This method is used to simplify the code, compare: > - old: CMS.getUserMessage(getLocale(), "CMS_ADMIN_SRVLT_NULL_RS_ID") > - new: getUserMessage("CMS_ADMIN_SRVLT_NULL_RS_ID") > > > But a better way to do > > this would be to specify locale the local as a protected variable in > > CMSResourceService.java. Then getLocale() would return this variable if > > it is non-null, or would find it from the headers. > > You mean caching the value returned by getLocale()? That can be done, > but the "locale" variable will be null until we call getLocale() at > least once. > > > Then you can call the regular CMS.getUserMessage(locale, ....) without > > the getUserMessage() calls. > > For this to work we'd have to set the "locale" first, so we need to call > getLocale() somewhere. I'm not sure if calling it in the > CMSResourceService constructor will work because the "headers" is > injected, which I suppose can only happen after the object is > constructed. We can call it in the beginning of each REST method, but > that's not pretty. So for now I'm keeping the getUserMessage(). > The problem with getUserMessage() is that you cannot call it from a non-RESTful servlet context. That is, you cannot call it from the old non-RESTful servlets. This is not important when you have implemented code that is completely independent of the old code (as in the case of the Users and Groups), but becomes a problem when you try to create modules that can be used by both the old and servlets. Maintaining two completely independent structures of code for the old servlets and the new ones will quickly become a maintenance nightmare. And the old servlets will stay around for a long time. Here is how I have been approaching this problem with regards to certificate issuance. 1. Create a class which contains the business logic of the process. In my case, I called it ProfileProcessor. The relevant servlet config and things like the locale are passed into the constructor of this object. 2. The object makes use of an Auditor, and maybe other classes like an Authenticator/ Authorizer. Ultimately, the Authenticator/Authorizer code will be moved into the Realm. 3. This class is instantiated by both the RESTful services and the old non-RESTful services. In both cases, we need to construct the ProfileProcessor, call the relevant function(s) and parse the results in the appropriate way. So, while I'm all for getMessage() functions, they need to be done in a way that can be called from a common class like the ProfileProcessor. Right now, you have them in a place where only the RESTful servlets can invoke them. Maybe, like in the case of the Auditor, we need a Logger or Utility class which takes the Locale on instantiation, and provides getMessage() calls. > > Its important we do it this way because when we are writing RESTful > > servlets for things like cert issuance and revocation, we want to try to > > reduce code duplication as much as possible. > > > > 5. Similar considerations exist for the audit() functions. We want to > > use existing functions so that code can be extracted and reused by both > > restful and restful servlets. > > It's been updated based on the new Auditor patch. > > > 6. Right now, the Delete user operation fails if the user is part of any > > groups. As discussed on #irc, we should create a resource > > at /users/{id}/groups for the client to check for group membership. And > > then allow the DELETE to remove users from groups automatically. > > Fixed. The user-group membership will be done in ticket #190. > > > 7. The paging mechanism in findUser() is not really the best - in that > > you basically get all of the results back from ldap each time. We > > really need paged searches instead. Its unlikely that this will be big > > concern for users/groups - but we should add a task to do proper paging. > > Right now it's using a very simple, maybe slower, but correct > implementation. To do paging properly we will need VLV or simple paged > results, which have their own limitations and possibly require sessions > (not RESTful). The UGSubsystem doesn't seem to support paging either. > How many users/groups do we need to be able to support? If its not large > probably the current solution is adequate. > agreed > > 8. The code in stripBrackets() and getEncodedCert() are used in many > > places in the code. After your changes, do all these still work? > > As discussed on IRC, the change in getEncodedCert() fixes the extra > blank line in certificates. The blank line got added when we change the > Base64 encoder/decoder sometime ago, so it's now back to the correct > behavior. > > The change in stripBrackets() has been removed. The > UserCertResourceService now normalizes the cert first. > From edewata at redhat.com Thu May 31 18:29:11 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 May 2012 13:29:11 -0500 Subject: [Pki-devel] [PATCH] 60 Added user REST service. In-Reply-To: <1338477629.3069.39.camel@aleeredhat.laptop> References: <4FBA5F38.70503@redhat.com> <1337886033.4525.101.camel@aleeredhat.laptop> <4FC5419F.40502@redhat.com> <1338477629.3069.39.camel@aleeredhat.laptop> Message-ID: <4FC7B877.4010503@redhat.com> On 5/31/2012 10:20 AM, Ade Lee wrote: > We appear to have come full circle. When I originally created the first > drm servlets, I put them under their own package separate from the old > "servlets" because they did not follow the servlet lifecycle - other > than going through the RESTEasy servlets. Based on review discussions, > we decided then to move them to be integrated with the existing code > structure. > > We need to rethink how all of this is packaged, keeping in mind some > sort of continuity between the old and new interfaces so that it is easy > to maintain. > > So, lets go ahead and check in for now, and then rearrange as makes > sense once we have carefully considered the packaging. OK, pushed to master. >>> 4. The getUserMessage() functions are perhaps not needed. If anything, >>> they should be written as a single vargs method. >> >> Changed to use varargs. This method is used to simplify the code, compare: >> - old: CMS.getUserMessage(getLocale(), "CMS_ADMIN_SRVLT_NULL_RS_ID") >> - new: getUserMessage("CMS_ADMIN_SRVLT_NULL_RS_ID") >> >>> But a better way to do >>> this would be to specify locale the local as a protected variable in >>> CMSResourceService.java. Then getLocale() would return this variable if >>> it is non-null, or would find it from the headers. >> >> You mean caching the value returned by getLocale()? That can be done, >> but the "locale" variable will be null until we call getLocale() at >> least once. >> >>> Then you can call the regular CMS.getUserMessage(locale, ....) without >>> the getUserMessage() calls. >> >> For this to work we'd have to set the "locale" first, so we need to call >> getLocale() somewhere. I'm not sure if calling it in the >> CMSResourceService constructor will work because the "headers" is >> injected, which I suppose can only happen after the object is >> constructed. We can call it in the beginning of each REST method, but >> that's not pretty. So for now I'm keeping the getUserMessage(). >> > The problem with getUserMessage() is that you cannot call it from a > non-RESTful servlet context. That is, you cannot call it from the old > non-RESTful servlets. This is not important when you have implemented > code that is completely independent of the old code (as in the case of > the Users and Groups), but becomes a problem when you try to create > modules that can be used by both the old and servlets. > > Maintaining two completely independent structures of code for the old > servlets and the new ones will quickly become a maintenance nightmare. > And the old servlets will stay around for a long time. > > Here is how I have been approaching this problem with regards to > certificate issuance. > 1. Create a class which contains the business logic of the process. In > my case, I called it ProfileProcessor. The relevant servlet config and > things like the locale are passed into the constructor of this object. > 2. The object makes use of an Auditor, and maybe other classes like an > Authenticator/ Authorizer. Ultimately, the Authenticator/Authorizer > code will be moved into the Realm. > 3. This class is instantiated by both the RESTful services and the old > non-RESTful services. In both cases, we need to construct the > ProfileProcessor, call the relevant function(s) and parse the results in > the appropriate way. > > So, while I'm all for getMessage() functions, they need to be done in a > way that can be called from a common class like the ProfileProcessor. > Right now, you have them in a place where only the RESTful servlets can > invoke them. Maybe, like in the case of the Auditor, we need a Logger > or Utility class which takes the Locale on instantiation, and provides > getMessage() calls. As discussed over IRC, the getUserMessage() is a convenience method which is specific to REST services similar to log() and audit() which we have specific implementations for CMSServlet and AdminServlet too. Common code such as UGSubsystem or the new ProfileProcessor should not rely on these methods. A better solution would be to use a different logger service that allows customization (ticket #195). -- Endi S. Dewata From edewata at redhat.com Thu May 31 18:30:18 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 May 2012 13:30:18 -0500 Subject: [Pki-devel] [PATCH] 61 Added user CLI. In-Reply-To: <4FC5420D.3050708@redhat.com> References: <4FBA613F.3090301@redhat.com> <4FC5420D.3050708@redhat.com> Message-ID: <4FC7B8BA.9090706@redhat.com> On 5/29/2012 4:39 PM, Endi Sukma Dewata wrote: > On 5/21/2012 10:37 AM, Endi Sukma Dewata wrote: >> The user CLI provides a tool to manage users and user certificates. >> >> Ticket #160 > > New patch attached. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu May 31 18:30:39 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 May 2012 13:30:39 -0500 Subject: [Pki-devel] [PATCH] 62 Added group REST service. In-Reply-To: <4FC54262.50906@redhat.com> References: <4FBA61E3.6030108@redhat.com> <4FC54262.50906@redhat.com> Message-ID: <4FC7B8CF.6000503@redhat.com> On 5/29/2012 4:40 PM, Endi Sukma Dewata wrote: > On 5/21/2012 10:40 AM, Endi Sukma Dewata wrote: >> The group REST service provides an interface to manage groups and group >> members. It is based on UsrGrpAdminServlet. >> >> Ticket #160 > > New patch attached. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu May 31 18:30:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 31 May 2012 13:30:57 -0500 Subject: [Pki-devel] [PATCH] 63 Added group CLI. In-Reply-To: <4FC542C4.4030109@redhat.com> References: <4FBA6235.5080109@redhat.com> <4FC542C4.4030109@redhat.com> Message-ID: <4FC7B8E1.4010608@redhat.com> On 5/29/2012 4:42 PM, Endi Sukma Dewata wrote: > On 5/21/2012 10:41 AM, Endi Sukma Dewata wrote: >> This patch provides a tool to manage groups and group members via >> command line. >> >> Ticket #160 > > New patch attached. ACKed by Ade. Pushed to master. -- Endi S. Dewata From akoneru at redhat.com Thu May 31 22:25:55 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 31 May 2012 18:25:55 -0400 Subject: [Pki-devel] [PATCH] Fixes for Some of the Coverity Issues under NULL_RETURNS category for Dog Tag 10 for Review Message-ID: <1338503155.8316.7.camel@abhishek> Please find attached the patch with fixes for some 40-50 defects of type NULL_RETURNS in Coverity for Dog Tag 10. Please review the patch The build passed Smoke Test. Thank you. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0009-Fixes-for-Null_Returns-Cases.patch Type: text/x-patch Size: 30948 bytes Desc: not available URL: