From jmagne at redhat.com Sat Mar 1 04:00:18 2014 From: jmagne at redhat.com (John Magne) Date: Fri, 28 Feb 2014 23:00:18 -0500 (EST) Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> Message-ID: <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> 0002-TPS-Rewrite-Requested-Review-Changes.patch TPS Rewrite Requested Review Changes: 1. Change the location of some of the classes. 2. Change the file names to reflect naming convention. 3. Change some of the method names to reflect convention. 4. Variable naming changes to reflect convention. ----- Original Message ----- From: "John Magne" To: "pki-devel" Sent: Wednesday, February 26, 2014 7:22:05 PM Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch First cut at Java TPS Buffer class and APDU classes. 1. Also simple framework for working with APDU commands. 2. Implemented a few APDU commands in TPS_Processor class. 3. Can now attempt a format operation with TPS client. The code can perform a few apdu's talking to the client and return a success "EndOp" apdu to terminate the conversation. 4. APDU are being encoded/decoded properly to appease tpsclient. More info. 1. Patch is large but most of it consists of many similar apdu and msg classes. 2. APDU and msg classes are now bare bones and may need more work. Will address when class is needed. 3. A test tpsclient script call it (format.tst) to test this out is as follows: op=var_set name=ra_host value=localhost op=var_set name=ra_port value=8080 op=var_set name=ra_uri value=/tps/tps op=token_set cuid=40906145C76224192D2B msn=0120304 app_ver=6FBBC105 key_info=0101 major_ver=1 minor_ver=1 op=token_set auth_key=404142434445464748494a4b4c4d4e4f op=token_set mac_key=404142434445464748494a4b4c4d4e4f op=token_set kek_key=404142434445464748494a4b4c4d4e4f op=ra_format uid=jmagne pwd=redhat new_pin=rehat num_threads=1 op=exit 4: Execute as follows: tpsclient < format.tst -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-TPS-Rewrite-Requested-Review-Changes.patch Type: text/x-patch Size: 321223 bytes Desc: not available URL: From akoneru at redhat.com Mon Mar 3 13:31:40 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 03 Mar 2014 08:31:40 -0500 Subject: [Pki-devel] [PATCH] 84 Change the return type of retrieve_key(key_id, twsk) in KeyClient (python) Message-ID: <1393853500.4195.3.camel@akoneru.redhat.com> The initial return of type tuple [KeyData, unwrapped_key] is replaced by returning just the KeyData object. The unwrapped key will be set as attribute 'private_data' of the KeyData object. Please review the attached patch with the above mentioned changes. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0084-Modify-return-object-for-retrieve_key-key_id-twsk.patch Type: text/x-patch Size: 4616 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 3 14:31:44 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Mar 2014 08:31:44 -0600 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <1393519239.4040.27.camel@localhost.localdomain> References: <5306414C.8060007@redhat.com> <1393519239.4040.27.camel@localhost.localdomain> Message-ID: <53149250.6060103@redhat.com> New patch #411-1 is attached. Patch #412-2 is unchanged. On 2/27/2014 10:40 AM, Ade Lee wrote: > 1. Typo in MainCLI.java : Mesage format Fixed. > 2. There appears to be no code to enforce the input to be "json or xml". > What if someone puts in "XML" or "Json" or "foo" in the CLI command > line? The original patch was case insensitive. If someone puts a value that doesn't translate to a valid MIME media type it will be rejected by the HTTP client library. The new patch now only accepts "xml" or "json", case sensitive. > 3. So, it looks like we have decided to remove all the Produces/Consumes > and basically provide all servlets as XML and JSON by default. What > that means though is that we are taking the logic of deciding which > format to return from the framework code. > > I'm a little confused as to why this is needed. Doesn't the framework > already do this work for us? As discussed on IRC, the hardcoded @Provides and @Consumes in the interface prevent java client from selecting the message format on demand. There are other options that have been considered (e.g. creating separate methods for each format, creating separate interfaces for client & server, moving the annotations to service classes, adding media type parameter to each method, adding enhancements to RESTEasy), but so far removing @Provides and @Consumes seems to be one solution that works with less changes to the server & client code and is available now. > What if the client requests a format like "application/atom-xml" - and > nothing else. If we follow your code, we will end up returning the > results in whatever format the request came in as. This seems wrong - > we should reject the request with a code 406 (not acceptable). And more > importantly - we should reject this prior to processing which is > presumably what the framework would do - rather than post-processing > when generating the response which is what your code does. The new patch utilizes a new interceptor to validate the acceptable message format before the operation is executed. It will throw error 415 on invalid request format and 406 on invalid response format, which is the same behavior in the existing code. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0411-1-Added-CLI-parameter-to-select-message-format.patch Type: text/x-patch Size: 19804 bytes Desc: not available URL: From cfu at redhat.com Tue Mar 4 00:14:04 2014 From: cfu at redhat.com (Christina Fu) Date: Mon, 03 Mar 2014 16:14:04 -0800 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem Message-ID: <53151ACC.1040309@redhat.com> The is a request for code review. Attached please find the code that implements the following trac ticket: https://fedorahosted.org/pki/ticket/862 TPS rewrite: provide connector service for JAVA-based TPS subsystem This patch makes available the connector that has been used between CA and KRA to TPS and other authorities (CA, TKS, KRA). A few things to note: 1. One key modification to the existing connector framework is the introduction of "muti-uri" implementation which will allow TPS to provide connectors according to an "op". For example: tps.connector.ca1.uri.enrollment=/ca/ee/ca/profileSubmitSSLClient tps.connector.ca1.uri.renewal=/ca/ee/ca/profileSubmitSSLClient tps.connector.ca1.uri.revoke=/ca/ee/subsystem/ca/doRevoke tps.connector.ca1.uri.unrevoke=/ca/ee/subsystem/ca/doUnrevoke In the above configuration, "renewal" is an op, which will match to the servlet /ca/ee/ca/profileSubmitSSLClient in the uri. 2. The connection configuration has been modified to take after the same style as that of the CA/KRA. - the change of target.Subsystem_Connections.pattern allows cli to work with the new connector parameters, however, the browser will show raw xml (it reports: "This XML file does not appear to have any style information associated with it. The document tree is shown below.") 3. Due to the unfilled parameters in the connector area, CS.cfg needs to be manually configured at this time. Which means you need to add "pki_skip_configuration=True" to your tps.cfg for pkispawn, and manually configure it. 4. Due to some unfortunate constant eclipse crashing issue, I had to manually visit each modified/added file to check for warnings. It is to my best knowledge that I did not add new warnings to the tree. 5. To know what NOT to expect in this ticket, please take a look of the following two tickets: https://fedorahosted.org/pki/ticket/888 - TPS rewrite: provide remote authority functions https://fedorahosted.org/pki/ticket/890 - TPS rewrite: connector configuration during installation thank you, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-trac-ticket-862-TPS-rewrite-provide-connector-servic.patch Type: text/x-patch Size: 59636 bytes Desc: not available URL: From edewata at redhat.com Tue Mar 4 00:18:59 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Mar 2014 18:18:59 -0600 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <53149250.6060103@redhat.com> References: <5306414C.8060007@redhat.com> <1393519239.4040.27.camel@localhost.localdomain> <53149250.6060103@redhat.com> Message-ID: <53151BF3.80809@redhat.com> New patch #411-2 is attached. It's now resolving the media types specified by the client (which may contain wildcards) into specific formats supported by the server. On 3/3/2014 8:31 AM, Endi Sukma Dewata wrote: > New patch #411-1 is attached. Patch #412-2 is unchanged. > > On 2/27/2014 10:40 AM, Ade Lee wrote: >> 1. Typo in MainCLI.java : Mesage format > > Fixed. > >> 2. There appears to be no code to enforce the input to be "json or xml". >> What if someone puts in "XML" or "Json" or "foo" in the CLI command >> line? > > The original patch was case insensitive. If someone puts a value that > doesn't translate to a valid MIME media type it will be rejected by the > HTTP client library. > > The new patch now only accepts "xml" or "json", case sensitive. > >> 3. So, it looks like we have decided to remove all the Produces/Consumes >> and basically provide all servlets as XML and JSON by default. What >> that means though is that we are taking the logic of deciding which >> format to return from the framework code. >> >> I'm a little confused as to why this is needed. Doesn't the framework >> already do this work for us? > > As discussed on IRC, the hardcoded @Provides and @Consumes in the > interface prevent java client from selecting the message format on > demand. There are other options that have been considered (e.g. creating > separate methods for each format, creating separate interfaces for > client & server, moving the annotations to service classes, adding media > type parameter to each method, adding enhancements to RESTEasy), but so > far removing @Provides and @Consumes seems to be one solution that works > with less changes to the server & client code and is available now. > >> What if the client requests a format like "application/atom-xml" - and >> nothing else. If we follow your code, we will end up returning the >> results in whatever format the request came in as. This seems wrong - >> we should reject the request with a code 406 (not acceptable). And more >> importantly - we should reject this prior to processing which is >> presumably what the framework would do - rather than post-processing >> when generating the response which is what your code does. > > The new patch utilizes a new interceptor to validate the acceptable > message format before the operation is executed. It will throw error 415 > on invalid request format and 406 on invalid response format, which is > the same behavior in the existing code. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0411-2-Added-CLI-parameter-to-select-message-format.patch Type: text/x-patch Size: 20369 bytes Desc: not available URL: From akoneru at redhat.com Tue Mar 4 02:16:15 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 3 Mar 2014 21:16:15 -0500 (EST) Subject: [Pki-devel] [PATCH] 85 Fix for exception thrown when unmarshalling *Request objects over XML In-Reply-To: <1358927028.6959548.1393899292244.JavaMail.zimbra@redhat.com> Message-ID: <1990029674.6959864.1393899375117.JavaMail.zimbra@redhat.com> Please review the attached patch which fixes the issue of JAXBContext not recogninzing the *Request classes as subclasses of ResourceMessage. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0085-Cannot-unmarshall-Request-objects-to-ResourceMessage.patch Type: text/x-patch Size: 2046 bytes Desc: not available URL: From akoneru at redhat.com Tue Mar 4 02:31:19 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 3 Mar 2014 21:31:19 -0500 (EST) Subject: [Pki-devel] [PATCH] 85 Fix for exception thrown when unmarshalling *Request objects over XML In-Reply-To: <1990029674.6959864.1393899375117.JavaMail.zimbra@redhat.com> References: <1990029674.6959864.1393899375117.JavaMail.zimbra@redhat.com> Message-ID: <2123088832.6961190.1393900279749.JavaMail.zimbra@redhat.com> Fixed Ade's comment, on IRC. Pushed to master. ----- Original Message ----- From: "Abhishek Koneru" To: "pki-devel" Sent: Monday, March 3, 2014 9:16:15 PM Subject: [Pki-devel] [PATCH] 85 Fix for exception thrown when unmarshalling *Request objects over XML Please review the attached patch which fixes the issue of JAXBContext not recogninzing the *Request classes as subclasses of ResourceMessage. --Abhishek _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Tue Mar 4 02:56:50 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 3 Mar 2014 21:56:50 -0500 (EST) Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <53151BF3.80809@redhat.com> References: <5306414C.8060007@redhat.com> <1393519239.4040.27.camel@localhost.localdomain> <53149250.6060103@redhat.com> <53151BF3.80809@redhat.com> Message-ID: <338108691.25682634.1393901810685.JavaMail.zimbra@redhat.com> Looks like this patch addresses alee's concerns. If its working fine ACK from me, but alee may have more specialized knowledge of this stuff, so consult him as well. ----- Original Message ----- From: "Endi Sukma Dewata" To: alee at redhat.com Cc: "pki-devel" Sent: Monday, March 3, 2014 4:18:59 PM Subject: Re: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. New patch #411-2 is attached. It's now resolving the media types specified by the client (which may contain wildcards) into specific formats supported by the server. On 3/3/2014 8:31 AM, Endi Sukma Dewata wrote: > New patch #411-1 is attached. Patch #412-2 is unchanged. > > On 2/27/2014 10:40 AM, Ade Lee wrote: >> 1. Typo in MainCLI.java : Mesage format > > Fixed. > >> 2. There appears to be no code to enforce the input to be "json or xml". >> What if someone puts in "XML" or "Json" or "foo" in the CLI command >> line? > > The original patch was case insensitive. If someone puts a value that > doesn't translate to a valid MIME media type it will be rejected by the > HTTP client library. > > The new patch now only accepts "xml" or "json", case sensitive. > >> 3. So, it looks like we have decided to remove all the Produces/Consumes >> and basically provide all servlets as XML and JSON by default. What >> that means though is that we are taking the logic of deciding which >> format to return from the framework code. >> >> I'm a little confused as to why this is needed. Doesn't the framework >> already do this work for us? > > As discussed on IRC, the hardcoded @Provides and @Consumes in the > interface prevent java client from selecting the message format on > demand. There are other options that have been considered (e.g. creating > separate methods for each format, creating separate interfaces for > client & server, moving the annotations to service classes, adding media > type parameter to each method, adding enhancements to RESTEasy), but so > far removing @Provides and @Consumes seems to be one solution that works > with less changes to the server & client code and is available now. > >> What if the client requests a format like "application/atom-xml" - and >> nothing else. If we follow your code, we will end up returning the >> results in whatever format the request came in as. This seems wrong - >> we should reject the request with a code 406 (not acceptable). And more >> importantly - we should reject this prior to processing which is >> presumably what the framework would do - rather than post-processing >> when generating the response which is what your code does. > > The new patch utilizes a new interceptor to validate the acceptable > message format before the operation is executed. It will throw error 415 > on invalid request format and 406 on invalid response format, which is > the same behavior in the existing code. -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Mar 4 15:19:24 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Mar 2014 10:19:24 -0500 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <338108691.25682634.1393901810685.JavaMail.zimbra@redhat.com> References: <5306414C.8060007@redhat.com> <1393519239.4040.27.camel@localhost.localdomain> <53149250.6060103@redhat.com> <53151BF3.80809@redhat.com> <338108691.25682634.1393901810685.JavaMail.zimbra@redhat.com> Message-ID: <1393946364.22935.1.camel@aleeredhat.laptop> For the most part, this looks good. I have only one question - what happens when a client passes in either no Accepts or no Content-Type header - or is this even possible? Thanks, Ade On Mon, 2014-03-03 at 21:56 -0500, John Magne wrote: > Looks like this patch addresses alee's concerns. > > If its working fine ACK from me, but alee may have more > specialized knowledge of this stuff, so consult him as well. > > ----- Original Message ----- > From: "Endi Sukma Dewata" > To: alee at redhat.com > Cc: "pki-devel" > Sent: Monday, March 3, 2014 4:18:59 PM > Subject: Re: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. > > New patch #411-2 is attached. It's now resolving the media types > specified by the client (which may contain wildcards) into specific > formats supported by the server. > > On 3/3/2014 8:31 AM, Endi Sukma Dewata wrote: > > New patch #411-1 is attached. Patch #412-2 is unchanged. > > > > On 2/27/2014 10:40 AM, Ade Lee wrote: > >> 1. Typo in MainCLI.java : Mesage format > > > > Fixed. > > > >> 2. There appears to be no code to enforce the input to be "json or xml". > >> What if someone puts in "XML" or "Json" or "foo" in the CLI command > >> line? > > > > The original patch was case insensitive. If someone puts a value that > > doesn't translate to a valid MIME media type it will be rejected by the > > HTTP client library. > > > > The new patch now only accepts "xml" or "json", case sensitive. > > > >> 3. So, it looks like we have decided to remove all the Produces/Consumes > >> and basically provide all servlets as XML and JSON by default. What > >> that means though is that we are taking the logic of deciding which > >> format to return from the framework code. > >> > >> I'm a little confused as to why this is needed. Doesn't the framework > >> already do this work for us? > > > > As discussed on IRC, the hardcoded @Provides and @Consumes in the > > interface prevent java client from selecting the message format on > > demand. There are other options that have been considered (e.g. creating > > separate methods for each format, creating separate interfaces for > > client & server, moving the annotations to service classes, adding media > > type parameter to each method, adding enhancements to RESTEasy), but so > > far removing @Provides and @Consumes seems to be one solution that works > > with less changes to the server & client code and is available now. > > > >> What if the client requests a format like "application/atom-xml" - and > >> nothing else. If we follow your code, we will end up returning the > >> results in whatever format the request came in as. This seems wrong - > >> we should reject the request with a code 406 (not acceptable). And more > >> importantly - we should reject this prior to processing which is > >> presumably what the framework would do - rather than post-processing > >> when generating the response which is what your code does. > > > > The new patch utilizes a new interceptor to validate the acceptable > > message format before the operation is executed. It will throw error 415 > > on invalid request format and 406 on invalid response format, which is > > the same behavior in the existing code. > From edewata at redhat.com Tue Mar 4 16:08:38 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 10:08:38 -0600 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <1393946364.22935.1.camel@aleeredhat.laptop> References: <5306414C.8060007@redhat.com> <1393519239.4040.27.camel@localhost.localdomain> <53149250.6060103@redhat.com> <53151BF3.80809@redhat.com> <338108691.25682634.1393901810685.JavaMail.zimbra@redhat.com> <1393946364.22935.1.camel@aleeredhat.laptop> Message-ID: <5315FA86.5010903@redhat.com> On 3/4/2014 9:19 AM, Ade Lee wrote: > For the most part, this looks good. > > I have only one question - what happens when a client passes in either > no Accepts or no Content-Type header - or is this even possible? > > Thanks, > Ade The Apache HTTP client for Java and python-requests libraries would generate those headers by default. Other clients such as curl and Firefox always generate those headers. I think this covers all clients that we want to support including IPA. I suppose someone could create a raw socket and send HTTP requests without those headers, but I don't think we want to support that. If the client doesn't tell the server what it's sending or how it wants the response back, the server is not required or may not be able to respond properly. -- Endi S. Dewata From edewata at redhat.com Tue Mar 4 17:36:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 11:36:52 -0600 Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> Message-ID: <53160F34.6010407@redhat.com> Some comments for patch #2: 1. Build failed due to uncompiled files. See javac command in base/common/src/CMakeLists.txt. The new namespace should be added into the javac command (sorry, I forgot to tell you about this). javac(pki-certsrv-classes SOURCES com/netscape/certsrv/*.java org/dogtagpki/*.java or it probably can be simplified as this: javac(pki-certsrv-classes SOURCES *.java And same thing with the packaging: jar(pki-certsrv-jar FILES *.class 2. Once issue #1 is fixed, there seem to be some dependency issues. The packages are built in this order: - base/common (client/common classes) - base/server/cms (server classes) - base/server/cmscore (legacy private server classes) - base/ A class cannot depend on another class in a lower package. So some classes may need to be refactored or shuffled around. 3. If TPSSession can only be used by the server, it should remain in base/tps-tomcat. If this is something a client might use, the dependency should be resolved and the package should be changed into org.dogtagpki.tps instead of org.dogtagpki.server.tps. 4. The TPSServlet probably should remain in base/tps-tomcat because it's a server class. 5. The org.dogtagpki.server.tps.engine.TPS class defines many constants. If the constants are used by clients the class probably should be moved to org.dogtagpki.tps.TPS. If the constants are used by server only, it probably should be moved to org.dogtagpki.server.tps.TPSServer, or maybe merged with TPSSubsystem. But if you'd like to keep it where it is now, it's probably better to call it TPSEngine. The "TPS" name should be reserved for namespace (e.g. defining constants, static methods). 6. There are some methods that start with uppercase: - APDU.Set*() - TPSFormatProcessor.Process() Generally Java methods start with lowercase. 7. An enumeration is used like a class, so it should follow class naming convention. So the TPSProcessor.TPS_Status probably shouldn't have an underscore in its name. 8. There are some classes with attributes defined at the bottom of the class. Usually a class is organized as follows: public class Something { // constants // attributes // constructors // methods } -- Endi S. Dewata On 2/28/2014 10:00 PM, John Magne wrote: > 0002-TPS-Rewrite-Requested-Review-Changes.patch > > > TPS Rewrite Requested Review Changes: > > 1. Change the location of some of the classes. > 2. Change the file names to reflect naming convention. > 3. Change some of the method names to reflect convention. > 4. Variable naming changes to reflect convention. > > > > > > ----- Original Message ----- > From: "John Magne" > To: "pki-devel" > Sent: Wednesday, February 26, 2014 7:22:05 PM > Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch > > First cut at Java TPS Buffer class and APDU classes. > > 1. Also simple framework for working with APDU commands. > 2. Implemented a few APDU commands in TPS_Processor class. > 3. Can now attempt a format operation with TPS client. > The code can perform a few apdu's talking to the client > and return a success "EndOp" apdu to terminate the conversation. > 4. APDU are being encoded/decoded properly to appease tpsclient. > > More info. > > 1. Patch is large but most of it consists of many similar apdu and msg classes. > 2. APDU and msg classes are now bare bones and may need more work. Will address when class is needed. > 3. A test tpsclient script call it (format.tst) to test this out is as follows: > > op=var_set name=ra_host value=localhost > op=var_set name=ra_port value=8080 > op=var_set name=ra_uri value=/tps/tps > op=token_set cuid=40906145C76224192D2B msn=0120304 app_ver=6FBBC105 key_info=0101 major_ver=1 minor_ver=1 > op=token_set auth_key=404142434445464748494a4b4c4d4e4f > op=token_set mac_key=404142434445464748494a4b4c4d4e4f > op=token_set kek_key=404142434445464748494a4b4c4d4e4f > op=ra_format uid=jmagne pwd=redhat new_pin=rehat num_threads=1 > op=exit > > 4: Execute as follows: > > tpsclient < format.tst From alee at redhat.com Tue Mar 4 19:23:55 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Mar 2014 14:23:55 -0500 Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client Message-ID: <1393961035.22935.4.camel@aleeredhat.laptop> This patch gets key archival working for the Key python client. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0206-Get-archival-working-for-python-key-client.patch Type: text/x-patch Size: 7042 bytes Desc: not available URL: From jmagne at redhat.com Tue Mar 4 22:27:14 2014 From: jmagne at redhat.com (John Magne) Date: Tue, 4 Mar 2014 17:27:14 -0500 (EST) Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <53160F34.6010407@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> <53160F34.6010407@redhat.com> Message-ID: <1931258818.26938185.1393972034881.JavaMail.zimbra@redhat.com> Endi thanks for the comments, resolutions below: ----- Original Message ----- > From: "Endi Sukma Dewata" > To: "John Magne" , "pki-devel" > Sent: Tuesday, March 4, 2014 9:36:52 AM > Subject: Re: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch > > Some comments for patch #2: > Done. Sorry, totally spaced building by script. > 1. Build failed due to uncompiled files. See javac command in > base/common/src/CMakeLists.txt. The new namespace should be added into > the javac command (sorry, I forgot to tell you about this). > > javac(pki-certsrv-classes > SOURCES > com/netscape/certsrv/*.java > org/dogtagpki/*.java > > or it probably can be simplified as this: > > javac(pki-certsrv-classes > SOURCES > *.java > > And same thing with the packaging: > > jar(pki-certsrv-jar > FILES > *.class Done, resolved by moving some things around. > 2. Once issue #1 is fixed, there seem to be some dependency issues. The > packages are built in this order: > - base/common (client/common classes) > - base/server/cms (server classes) > - base/server/cmscore (legacy private server classes) > - base/ > A class cannot depend on another class in a lower package. So some > classes may need to be refactored or shuffled around. > Done. > 3. If TPSSession can only be used by the server, it should remain in > base/tps-tomcat. If this is something a client might use, the dependency > should be resolved and the package should be changed into > org.dogtagpki.tps instead of org.dogtagpki.server.tps. > > 4. The TPSServlet probably should remain in base/tps-tomcat because it's > a server class. Decided to take advice to leave and rename as TPSEngine, right now their are only defines, but later will be functionality used by the server. > > 5. The org.dogtagpki.server.tps.engine.TPS class defines many constants. > If the constants are used by clients the class probably should be moved > to org.dogtagpki.tps.TPS. If the constants are used by server only, it > probably should be moved to org.dogtagpki.server.tps.TPSServer, or maybe > merged with TPSSubsystem. But if you'd like to keep it where it is now, > it's probably better to call it TPSEngine. The "TPS" name should be > reserved for namespace (e.g. defining constants, static methods). > Done, sorry some of them simply escaped detection, they are elusive :) > 6. There are some methods that start with uppercase: > - APDU.Set*() > - TPSFormatProcessor.Process() > Generally Java methods start with lowercase. Done. > > 7. An enumeration is used like a class, so it should follow class naming > convention. So the TPSProcessor.TPS_Status probably shouldn't have an > underscore in its name. > Done. Pretty sure I got all the examples of this. > 8. There are some classes with attributes defined at the bottom of the > class. Usually a class is organized as follows: > > public class Something { > // constants > // attributes > // constructors > // methods > } > > -- > Endi S. Dewata > > > On 2/28/2014 10:00 PM, John Magne wrote: > > 0002-TPS-Rewrite-Requested-Review-Changes.patch > > > > > > TPS Rewrite Requested Review Changes: > > > > 1. Change the location of some of the classes. > > 2. Change the file names to reflect naming convention. > > 3. Change some of the method names to reflect convention. > > 4. Variable naming changes to reflect convention. > > > > > > > > > > > > ----- Original Message ----- > > From: "John Magne" > > To: "pki-devel" > > Sent: Wednesday, February 26, 2014 7:22:05 PM > > Subject: [Pki-devel] [PATCH] > > 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch > > > > First cut at Java TPS Buffer class and APDU classes. > > > > 1. Also simple framework for working with APDU commands. > > 2. Implemented a few APDU commands in TPS_Processor class. > > 3. Can now attempt a format operation with TPS client. > > The code can perform a few apdu's talking to the client > > and return a success "EndOp" apdu to terminate the conversation. > > 4. APDU are being encoded/decoded properly to appease tpsclient. > > > > More info. > > > > 1. Patch is large but most of it consists of many similar apdu and msg > > classes. > > 2. APDU and msg classes are now bare bones and may need more work. Will > > address when class is needed. > > 3. A test tpsclient script call it (format.tst) to test this out is as > > follows: > > > > op=var_set name=ra_host value=localhost > > op=var_set name=ra_port value=8080 > > op=var_set name=ra_uri value=/tps/tps > > op=token_set cuid=40906145C76224192D2B msn=0120304 app_ver=6FBBC105 > > key_info=0101 major_ver=1 minor_ver=1 > > op=token_set auth_key=404142434445464748494a4b4c4d4e4f > > op=token_set mac_key=404142434445464748494a4b4c4d4e4f > > op=token_set kek_key=404142434445464748494a4b4c4d4e4f > > op=ra_format uid=jmagne pwd=redhat new_pin=rehat num_threads=1 > > op=exit > > > > 4: Execute as follows: > > > > tpsclient < format.tst > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Further-TPS-Rewrite-Requested-Review-Changes.patch Type: text/x-patch Size: 88204 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 5 00:29:05 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 18:29:05 -0600 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <53151ACC.1040309@redhat.com> References: <53151ACC.1040309@redhat.com> Message-ID: <53166FD1.2090804@redhat.com> Some comments: 1. As discussed over IRC the common code HttpConnection shouldn't contain a subsystem-specific code, which in this case is setting the content type to application/x-www-form-urlencoded for TPS. 2. Also discussed over IRC, there's an existing issue with HttpConnection constructors: https://fedorahosted.org/pki/ticket/891 Suppose that issue is fixed later, it should be possible to merge the constructors. Then instead of calling different constructors for different timeout values like this: if (timeout == 0) { connector = new HttpConnector( null, nickname, remauthority, resendInterval, conf); } else { connector = new HttpConnector( null, nickname, remauthority, resendInterval, conf, timeout); } it can be simplified like this: connector = new HttpConnector( null, nickname, remauthority, resendInterval, conf, timeout); There's also a similar code in HttpConnFactory. 4. In HttpConnection the existing constructors were changed to pass "" as the default value of op. I think we should just pass a null value. This way the code can simply check the op like this: this(dest, factory, null); ... if (op == null) If we really want to accept an empty string, then probably we should normalize the string by trimming the white spaces before checking for empty string. 5. The HttpConnection.send() checks if the parameter is null or empty string then returns a null value with a comment "throw later". This error will only be detected later if another code tries to use the null return value, but at that point we're looking at a secondary issue, which makes it harder to troubleshoot. I think in general it's better to throw an exception as soon as the error is detected. 6. The HttpConnection.send() checks for untrusted certificate by checking the exception message. This may work now but could become inaccurate later due to translation, text changes, or typo. It would be better if there's a specific exception type or error code that we can check for this specific case. 7. Similar to #5, HttpConnection.send() swallows NumberFormatException. I think we should not catch this to detect the error as early as possible and also NumberFormatException is already a RuntimeException so it doesn't need to be wrapped/declared. 8. Similar to #5, the HttpConnector.send() (not HttpConnection) would swallow the exception so some errors wouldn't be detected immediately. I think the code could be simplified as follows (the send() already throws EBaseException): try { curConn = mConnFactory.getConn(op); return curConn.send(msg); } finally { if (curConn != null) { mConnFactory.returnConn(curConn); } } 9. Similar to #5, the ConnectionManager.getXMLparser() would swallow the exceptions. I think it would be better to wrap the exception in a RuntimeException and rethrow it. try { ByteArrayInputStream bis = new ByteArrayInputStream(text.getBytes()); return new XMLObject(bis); } catch (Exception e) { CMS.debug("TPSSubsystem: getXMLparser(): failed: "+ e.toString()); throw new RuntimeException(e); } We can change this code again in the future if necessary to use a more specific class or add the original exceptions into the throws list. 10. In ConnectionManager, the createConnector() will never return a null, so it's not necessary to check its return value in initConnectors(). It will simplify the code and some code analyzers like Coverity probably will report the part that handles the null case as dead code anyway. 11. Just some minor things: - The debug log in getXMLparser() should say "ConnectionManager" instead of "TPSSubsystem". - If we use camel-case consistently, the name should be getXMLParser() (with upper-case P). - Some toString() invocations are redundant because string concatenation will call it automatically. I'll leave it to others to review the functionality correctness. -- Endi S. Dewata On 3/3/2014 6:14 PM, Christina Fu wrote: > The is a request for code review. > > Attached please find the code that implements the following trac ticket: > https://fedorahosted.org/pki/ticket/862 TPS rewrite: provide connector > service for JAVA-based TPS subsystem > > This patch makes available the connector that has been used between CA > and KRA to TPS and other authorities (CA, TKS, KRA). > > A few things to note: > 1. > One key modification to the existing connector framework is the > introduction of "muti-uri" implementation which will allow TPS to > provide connectors according to an "op". For example: > tps.connector.ca1.uri.enrollment=/ca/ee/ca/profileSubmitSSLClient > tps.connector.ca1.uri.renewal=/ca/ee/ca/profileSubmitSSLClient > tps.connector.ca1.uri.revoke=/ca/ee/subsystem/ca/doRevoke > tps.connector.ca1.uri.unrevoke=/ca/ee/subsystem/ca/doUnrevoke > In the above configuration, "renewal" is an op, which will match to the > servlet /ca/ee/ca/profileSubmitSSLClient in the uri. > > 2. > The connection configuration has been modified to take after the same > style as that of the CA/KRA. > - the change of target.Subsystem_Connections.pattern allows cli to > work with the new connector parameters, however, the browser will show > raw xml (it reports: "This XML file does not appear to have any style > information associated with it. The document tree is shown below.") > > 3. > Due to the unfilled parameters in the connector area, CS.cfg needs to be > manually configured at this time. Which means you need to add > "pki_skip_configuration=True" to your tps.cfg for pkispawn, and manually > configure it. > > 4. > Due to some unfortunate constant eclipse crashing issue, I had to > manually visit each modified/added file to check for warnings. It is to > my best knowledge that I did not add new warnings to the tree. > > 5. > To know what NOT to expect in this ticket, please take a look of the > following two tickets: > https://fedorahosted.org/pki/ticket/888 - TPS rewrite: provide remote > authority functions > https://fedorahosted.org/pki/ticket/890 - TPS rewrite: connector > configuration during installation > > thank you, > Christina From akoneru at redhat.com Wed Mar 5 01:13:26 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 4 Mar 2014 20:13:26 -0500 (EST) Subject: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side In-Reply-To: <815171948.7252027.1393981817255.JavaMail.zimbra@redhat.com> Message-ID: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> Please review the attached patch which replicates the new python client's KeyClient class on the Java side. --Abhishek. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0086-Changes-to-KeyClient-on-the-java-side.patch Type: text/x-patch Size: 71664 bytes Desc: not available URL: From jmagne at redhat.com Wed Mar 5 01:52:07 2014 From: jmagne at redhat.com (John Magne) Date: Tue, 4 Mar 2014 20:52:07 -0500 (EST) Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client In-Reply-To: <1393961035.22935.4.camel@aleeredhat.laptop> References: <1393961035.22935.4.camel@aleeredhat.laptop> Message-ID: <167984990.27017110.1393984327610.JavaMail.zimbra@redhat.com> Ade: Looks good, just a question. 1. This code here: def setup_contexts(mechanism, sym_key, nonce_iv): .... # If initialization vector was supplied use it, otherwise set it to None if nonce_iv: iv_si = nss.SecItem(nonce_iv) iv_param = nss.param_from_iv(mechanism, iv_si) else: iv_length = nss.get_iv_length(mechanism) if iv_length > 0: iv_data = nss.generate_random(iv_length) iv_si = nss.SecItem(iv_data) iv_param = nss.param_from_iv(mechanism, iv_si) else: iv_param = None Note the else clause where we generate an init vector. Can we use the nice method you provided "generate_nonce_iv" to do this? ----- Original Message ----- > From: "Ade Lee" > To: pki-devel at redhat.comgenerate_nonce_iv > Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client > > This patch gets key archival working for the Key python client. > > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Mar 5 02:26:22 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 20:26:22 -0600 Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client In-Reply-To: <1393961035.22935.4.camel@aleeredhat.laptop> References: <1393961035.22935.4.camel@aleeredhat.laptop> Message-ID: <53168B4E.2000902@redhat.com> On 3/4/2014 1:23 PM, Ade Lee wrote: > This patch gets key archival working for the Key python client. > > Ade Not sure if this is correct. Test #19 archives key1 with a new client_key_id. I suppose this will generate a new key record with a new key_id. Test #20 is getting the key_info with the above client_key_id, but then it retrieves the key data using an old key_id obtained from test #4, not from the key_info just obtained. Is the test comparing the right keys? -- Endi S. Dewata From edewata at redhat.com Wed Mar 5 02:40:38 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 20:40:38 -0600 Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <1931258818.26938185.1393972034881.JavaMail.zimbra@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> <53160F34.6010407@redhat.com> <1931258818.26938185.1393972034881.JavaMail.zimbra@redhat.com> Message-ID: <53168EA6.7040309@redhat.com> Great! Thanks for your patience :) ACK for patch #1-3. -- Endi S. Dewata On 3/4/2014 4:27 PM, John Magne wrote: > Endi thanks for the comments, resolutions below: > > > > > ----- Original Message ----- >> From: "Endi Sukma Dewata" >> To: "John Magne" , "pki-devel" >> Sent: Tuesday, March 4, 2014 9:36:52 AM >> Subject: Re: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch >> >> Some comments for patch #2: >> > > > Done. Sorry, totally spaced building by script. > > >> 1. Build failed due to uncompiled files. See javac command in >> base/common/src/CMakeLists.txt. The new namespace should be added into >> the javac command (sorry, I forgot to tell you about this). >> >> javac(pki-certsrv-classes >> SOURCES >> com/netscape/certsrv/*.java >> org/dogtagpki/*.java >> >> or it probably can be simplified as this: >> >> javac(pki-certsrv-classes >> SOURCES >> *.java >> >> And same thing with the packaging: >> >> jar(pki-certsrv-jar >> FILES >> *.class > > > Done, resolved by moving some things around. > >> 2. Once issue #1 is fixed, there seem to be some dependency issues. The >> packages are built in this order: >> - base/common (client/common classes) >> - base/server/cms (server classes) >> - base/server/cmscore (legacy private server classes) >> - base/ >> A class cannot depend on another class in a lower package. So some >> classes may need to be refactored or shuffled around. >> > > > Done. > > >> 3. If TPSSession can only be used by the server, it should remain in >> base/tps-tomcat. If this is something a client might use, the dependency >> should be resolved and the package should be changed into >> org.dogtagpki.tps instead of org.dogtagpki.server.tps. >> >> 4. The TPSServlet probably should remain in base/tps-tomcat because it's >> a server class. > > > > Decided to take advice to leave and rename as TPSEngine, right now their > are only defines, but later will be functionality used by the server. > >> >> 5. The org.dogtagpki.server.tps.engine.TPS class defines many constants. >> If the constants are used by clients the class probably should be moved >> to org.dogtagpki.tps.TPS. If the constants are used by server only, it >> probably should be moved to org.dogtagpki.server.tps.TPSServer, or maybe >> merged with TPSSubsystem. But if you'd like to keep it where it is now, >> it's probably better to call it TPSEngine. The "TPS" name should be >> reserved for namespace (e.g. defining constants, static methods). >> > > > Done, sorry some of them simply escaped detection, they are elusive :) > > >> 6. There are some methods that start with uppercase: >> - APDU.Set*() >> - TPSFormatProcessor.Process() >> Generally Java methods start with lowercase. > > > > Done. >> >> 7. An enumeration is used like a class, so it should follow class naming >> convention. So the TPSProcessor.TPS_Status probably shouldn't have an >> underscore in its name. >> > > > Done. Pretty sure I got all the examples of this. > > >> 8. There are some classes with attributes defined at the bottom of the >> class. Usually a class is organized as follows: >> >> public class Something { >> // constants >> // attributes >> // constructors >> // methods >> } From jmagne at redhat.com Wed Mar 5 02:49:40 2014 From: jmagne at redhat.com (John Magne) Date: Tue, 4 Mar 2014 21:49:40 -0500 (EST) Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client In-Reply-To: <53168B4E.2000902@redhat.com> References: <1393961035.22935.4.camel@aleeredhat.laptop> <53168B4E.2000902@redhat.com> Message-ID: <841959778.27048329.1393987780078.JavaMail.zimbra@redhat.com> I think you are correct, but they may be the same keys anway. He looks like he has the same key archived under two different id's. He's retrieving it at the end using the old id. ----- Original Message ----- > From: "Endi Sukma Dewata" > To: alee at redhat.com, pki-devel at redhat.com > Sent: Tuesday, March 4, 2014 6:26:22 PM > Subject: Re: [Pki-devel] [PATCH] 206 - get archival working in python key client > > On 3/4/2014 1:23 PM, Ade Lee wrote: > > This patch gets key archival working for the Key python client. > > > > Ade > > Not sure if this is correct. > > Test #19 archives key1 with a new client_key_id. I suppose this will > generate a new key record with a new key_id. > > Test #20 is getting the key_info with the above client_key_id, but then > it retrieves the key data using an old key_id obtained from test #4, not > from the key_info just obtained. Is the test comparing the right keys? > > -- > Endi S. Dewata > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From edewata at redhat.com Wed Mar 5 03:13:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 21:13:37 -0600 Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client In-Reply-To: <841959778.27048329.1393987780078.JavaMail.zimbra@redhat.com> References: <1393961035.22935.4.camel@aleeredhat.laptop> <53168B4E.2000902@redhat.com> <841959778.27048329.1393987780078.JavaMail.zimbra@redhat.com> Message-ID: <53169661.9020801@redhat.com> Yes, they are the same keys, but in this case test #20 might report a false positive. The key generated in test #4 is already validated in tests #7 and #8. Test #20 basically repeats those steps. The key archived in test #19 is not validated, which I suppose is the purpose of test #20. -- Endi S. Dewata On 3/4/2014 8:49 PM, John Magne wrote: > I think you are correct, but they may be the same keys anway. > > He looks like he has the same key archived under two different id's. > He's retrieving it at the end using the old id. > >> Not sure if this is correct. >> >> Test #19 archives key1 with a new client_key_id. I suppose this will >> generate a new key record with a new key_id. >> >> Test #20 is getting the key_info with the above client_key_id, but then >> it retrieves the key data using an old key_id obtained from test #4, not >> from the key_info just obtained. Is the test comparing the right keys? From edewata at redhat.com Wed Mar 5 03:49:38 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 21:49:38 -0600 Subject: [Pki-devel] [PATCH] 411 Added CLI parameter to select message format. In-Reply-To: <5315FA86.5010903@redhat.com> References: <5306414C.8060007@redhat.com> <1393519239.4040.27.camel@localhost.localdomain> <53149250.6060103@redhat.com> <53151BF3.80809@redhat.com> <338108691.25682634.1393901810685.JavaMail.zimbra@redhat.com> <1393946364.22935.1.camel@aleeredhat.laptop> <5315FA86.5010903@redhat.com> Message-ID: <53169ED2.5070007@redhat.com> On 3/4/2014 10:08 AM, Endi Sukma Dewata wrote: > On 3/4/2014 9:19 AM, Ade Lee wrote: >> For the most part, this looks good. >> >> I have only one question - what happens when a client passes in either >> no Accepts or no Content-Type header - or is this even possible? >> >> Thanks, >> Ade > > The Apache HTTP client for Java and python-requests libraries would > generate those headers by default. Other clients such as curl and > Firefox always generate those headers. I think this covers all clients > that we want to support including IPA. > > I suppose someone could create a raw socket and send HTTP requests > without those headers, but I don't think we want to support that. If the > client doesn't tell the server what it's sending or how it wants the > response back, the server is not required or may not be able to respond > properly. > ACKed by Jack & Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Mar 5 03:49:56 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Mar 2014 21:49:56 -0600 Subject: [Pki-devel] [PATCH] 412 Removed @Consumes and @Provides. In-Reply-To: <1393519339.4040.28.camel@localhost.localdomain> References: <530641C2.2070709@redhat.com> <5306822D.8070105@redhat.com> <530F5C8E.9040005@redhat.com> <1393519339.4040.28.camel@localhost.localdomain> Message-ID: <53169EE4.8000609@redhat.com> On 2/27/2014 10:42 AM, Ade Lee wrote: > NACK - based on comment on patch 411. ACKed on IRC based on #411-2. Pushed to master. -- Endi S. Dewata From alee at redhat.com Wed Mar 5 17:03:35 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 05 Mar 2014 12:03:35 -0500 Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client In-Reply-To: <53169661.9020801@redhat.com> References: <1393961035.22935.4.camel@aleeredhat.laptop> <53168B4E.2000902@redhat.com> <841959778.27048329.1393987780078.JavaMail.zimbra@redhat.com> <53169661.9020801@redhat.com> Message-ID: <1394039015.2689.28.camel@aleeredhat.laptop> Good catch on the test. I updated the test and changed the code as Jack suggested. Updated patch attached. This one supersedes the old one. Ade On Tue, 2014-03-04 at 21:13 -0600, Endi Sukma Dewata wrote: > Yes, they are the same keys, but in this case test #20 might report a > false positive. > > The key generated in test #4 is already validated in tests #7 and #8. > Test #20 basically repeats those steps. The key archived in test #19 is > not validated, which I suppose is the purpose of test #20. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0206-1-Get-archival-working-for-python-key-client.patch Type: text/x-patch Size: 7481 bytes Desc: not available URL: From alee at redhat.com Wed Mar 5 17:09:08 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 05 Mar 2014 12:09:08 -0500 Subject: [Pki-devel] [PATCH] 206 - get archival working in python key client In-Reply-To: <1394039015.2689.28.camel@aleeredhat.laptop> References: <1393961035.22935.4.camel@aleeredhat.laptop> <53168B4E.2000902@redhat.com> <841959778.27048329.1393987780078.JavaMail.zimbra@redhat.com> <53169661.9020801@redhat.com> <1394039015.2689.28.camel@aleeredhat.laptop> Message-ID: <1394039348.2689.29.camel@aleeredhat.laptop> acked by Endi. Pushed to master. On Wed, 2014-03-05 at 12:03 -0500, Ade Lee wrote: > Good catch on the test. > > I updated the test and changed the code as Jack suggested. Updated > patch attached. This one supersedes the old one. > > Ade > > On Tue, 2014-03-04 at 21:13 -0600, Endi Sukma Dewata wrote: > > Yes, they are the same keys, but in this case test #20 might report a > > false positive. > > > > The key generated in test #4 is already validated in tests #7 and #8. > > Test #20 basically repeats those steps. The key archived in test #19 is > > not validated, which I suppose is the purpose of test #20. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Mar 5 17:34:33 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 05 Mar 2014 12:34:33 -0500 Subject: [Pki-devel] [PATCH] 84 Change the return type of retrieve_key(key_id, twsk) in KeyClient (python) In-Reply-To: <1393853500.4195.3.camel@akoneru.redhat.com> References: <1393853500.4195.3.camel@akoneru.redhat.com> Message-ID: <1394040873.2689.35.camel@aleeredhat.laptop> ACK - with the following caveats. 1. in key.py, add a blank line before # To store the unwrapped ... 2. The logic in retrieve_key() can be condensed : if not key_provided: unwrapped_key = self.crypto.symmetric_unwrap( key_data.wrappedPrivateData, session_key, nonce_iv=key_data.nonceData) key_data.private_data = unwrapped_key return key_data 3. There is a test that has been added to the end of drmtest.py that uses retrieve_key. It needs to be modified. Make sure to run through drmtest.py once again to confirm that it all works. Ade On Mon, 2014-03-03 at 08:31 -0500, Abhishek Koneru wrote: > The initial return of type tuple [KeyData, unwrapped_key] is replaced by > returning just the KeyData object. The unwrapped key will be set as > attribute 'private_data' of the KeyData object. > > Please review the attached patch with the above mentioned changes. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Wed Mar 5 18:12:19 2014 From: jmagne at redhat.com (John Magne) Date: Wed, 5 Mar 2014 13:12:19 -0500 (EST) Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <53168EA6.7040309@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> <53160F34.6010407@redhat.com> <1931258818.26938185.1393972034881.JavaMail.zimbra@redhat.com> <53168EA6.7040309@redhat.com> Message-ID: <1680038252.27890900.1394043139592.JavaMail.zimbra@redhat.com> ACKED by edewata,cfu. Pushed to master. ----- Original Message ----- From: "Endi Sukma Dewata" To: "John Magne" Cc: "pki-devel" Sent: Tuesday, March 4, 2014 6:40:38 PM Subject: Re: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch Great! Thanks for your patience :) ACK for patch #1-3. -- Endi S. Dewata On 3/4/2014 4:27 PM, John Magne wrote: > Endi thanks for the comments, resolutions below: > > > > > ----- Original Message ----- >> From: "Endi Sukma Dewata" >> To: "John Magne" , "pki-devel" >> Sent: Tuesday, March 4, 2014 9:36:52 AM >> Subject: Re: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch >> >> Some comments for patch #2: >> > > > Done. Sorry, totally spaced building by script. > > >> 1. Build failed due to uncompiled files. See javac command in >> base/common/src/CMakeLists.txt. The new namespace should be added into >> the javac command (sorry, I forgot to tell you about this). >> >> javac(pki-certsrv-classes >> SOURCES >> com/netscape/certsrv/*.java >> org/dogtagpki/*.java >> >> or it probably can be simplified as this: >> >> javac(pki-certsrv-classes >> SOURCES >> *.java >> >> And same thing with the packaging: >> >> jar(pki-certsrv-jar >> FILES >> *.class > > > Done, resolved by moving some things around. > >> 2. Once issue #1 is fixed, there seem to be some dependency issues. The >> packages are built in this order: >> - base/common (client/common classes) >> - base/server/cms (server classes) >> - base/server/cmscore (legacy private server classes) >> - base/ >> A class cannot depend on another class in a lower package. So some >> classes may need to be refactored or shuffled around. >> > > > Done. > > >> 3. If TPSSession can only be used by the server, it should remain in >> base/tps-tomcat. If this is something a client might use, the dependency >> should be resolved and the package should be changed into >> org.dogtagpki.tps instead of org.dogtagpki.server.tps. >> >> 4. The TPSServlet probably should remain in base/tps-tomcat because it's >> a server class. > > > > Decided to take advice to leave and rename as TPSEngine, right now their > are only defines, but later will be functionality used by the server. > >> >> 5. The org.dogtagpki.server.tps.engine.TPS class defines many constants. >> If the constants are used by clients the class probably should be moved >> to org.dogtagpki.tps.TPS. If the constants are used by server only, it >> probably should be moved to org.dogtagpki.server.tps.TPSServer, or maybe >> merged with TPSSubsystem. But if you'd like to keep it where it is now, >> it's probably better to call it TPSEngine. The "TPS" name should be >> reserved for namespace (e.g. defining constants, static methods). >> > > > Done, sorry some of them simply escaped detection, they are elusive :) > > >> 6. There are some methods that start with uppercase: >> - APDU.Set*() >> - TPSFormatProcessor.Process() >> Generally Java methods start with lowercase. > > > > Done. >> >> 7. An enumeration is used like a class, so it should follow class naming >> convention. So the TPSProcessor.TPS_Status probably shouldn't have an >> underscore in its name. >> > > > Done. Pretty sure I got all the examples of this. > > >> 8. There are some classes with attributes defined at the bottom of the >> class. Usually a class is organized as follows: >> >> public class Something { >> // constants >> // attributes >> // constructors >> // methods >> } From edewata at redhat.com Wed Mar 5 19:15:34 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Mar 2014 13:15:34 -0600 Subject: [Pki-devel] [PATCH] 414 Direct deployment for TPS. In-Reply-To: <530CFBED.60605@redhat.com> References: <530CFBED.60605@redhat.com> Message-ID: <531777D6.6070504@redhat.com> New patch attached. Fixed a problem creating symlinks. -- Endi S. Dewata On 2/25/2014 2:24 PM, Endi Sukma Dewata wrote: > The deployment tool has been modified to deploy TPS directly from the > share folder. This way the TPS UI can be upgraded automatically with > RPM upgrade without having to write upgrade scripts. > > For this to work, the TPS web application files cannot contain any > customization. So, the cfgPath parameter has been removed from web.xml, > and the CMSStartServlet has been modified such that if the parameter is > missing it would generate a default path matching the original value in > web.xml. Also, the velocity.properties has been modified to use a fixed > value for the file.resource.loader.path parameter pointing to the share > folder. > > In the future other subsystems may be modified to use the same > deployment mechanism. > > Ticket #748, #752, #499 -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0414-1-Direct-deployment-for-TPS.patch Type: text/x-patch Size: 14061 bytes Desc: not available URL: From cfu at redhat.com Thu Mar 6 00:12:10 2014 From: cfu at redhat.com (Christina Fu) Date: Wed, 05 Mar 2014 16:12:10 -0800 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <53166FD1.2090804@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> Message-ID: <5317BD5A.8050804@redhat.com> Hi, First of all, thank you Endi for your through review. Per irc discussions, I have filed the following tickets: * https://fedorahosted.org/pki/ticket/892 Need better error handling for HttpConnection send() - this ticket will address the comments irt pre-existing code * https://fedorahosted.org/pki/ticket/893 subsystems (ca, kra, tks, tps) mixed-up their subsystem certs when sharing same Tomcat instance - this ticket will provide investigation for an issue I found irt shared tomcat instance causing mixed-up subsystem certs among subsystems Attached please find the patch that addressed the remaining comments. thanks, Christina On 03/04/2014 04:29 PM, Endi Sukma Dewata wrote: > Some comments: > > 1. As discussed over IRC the common code HttpConnection shouldn't > contain a subsystem-specific code, which in this case is setting the > content type to application/x-www-form-urlencoded for TPS. > > 2. Also discussed over IRC, there's an existing issue with > HttpConnection constructors: > https://fedorahosted.org/pki/ticket/891 > > Suppose that issue is fixed later, it should be possible to merge the > constructors. Then instead of calling different constructors for > different timeout values like this: > > if (timeout == 0) { > connector = > new HttpConnector( > null, nickname, remauthority, > resendInterval, conf); > } else { > connector = > new HttpConnector( > null, nickname, remauthority, > resendInterval, conf, timeout); > } > > it can be simplified like this: > > connector = > new HttpConnector( > null, nickname, remauthority, > resendInterval, conf, timeout); > > There's also a similar code in HttpConnFactory. > > 4. In HttpConnection the existing constructors were changed to pass "" > as the default value of op. I think we should just pass a null value. > This way the code can simply check the op like this: > > this(dest, factory, null); > > ... > > if (op == null) > > If we really want to accept an empty string, then probably we should > normalize the string by trimming the white spaces before checking for > empty string. > > 5. The HttpConnection.send() checks if the parameter is null or empty > string then returns a null value with a comment "throw later". This > error will only be detected later if another code tries to use the > null return value, but at that point we're looking at a secondary > issue, which makes it harder to troubleshoot. I think in general it's > better to throw an exception as soon as the error is detected. > > 6. The HttpConnection.send() checks for untrusted certificate by > checking the exception message. This may work now but could become > inaccurate later due to translation, text changes, or typo. It would > be better if there's a specific exception type or error code that we > can check for this specific case. > > 7. Similar to #5, HttpConnection.send() swallows > NumberFormatException. I think we should not catch this to detect the > error as early as possible and also NumberFormatException is already a > RuntimeException so it doesn't need to be wrapped/declared. > > 8. Similar to #5, the HttpConnector.send() (not HttpConnection) would > swallow the exception so some errors wouldn't be detected immediately. > I think the code could be simplified as follows (the send() already > throws EBaseException): > > try { > curConn = mConnFactory.getConn(op); > return curConn.send(msg); > > } finally { > if (curConn != null) { > mConnFactory.returnConn(curConn); > } > } > > 9. Similar to #5, the ConnectionManager.getXMLparser() would swallow > the exceptions. I think it would be better to wrap the exception in a > RuntimeException and rethrow it. > > try { > ByteArrayInputStream bis = > new ByteArrayInputStream(text.getBytes()); > return new XMLObject(bis); > > } catch (Exception e) { > CMS.debug("TPSSubsystem: getXMLparser(): failed: "+ > e.toString()); > throw new RuntimeException(e); > } > > We can change this code again in the future if necessary to use a more > specific class or add the original exceptions into the throws list. > > 10. In ConnectionManager, the createConnector() will never return a > null, so it's not necessary to check its return value in > initConnectors(). It will simplify the code and some code analyzers > like Coverity probably will report the part that handles the null case > as dead code anyway. > > 11. Just some minor things: > - The debug log in getXMLparser() should say "ConnectionManager" > instead of "TPSSubsystem". > - If we use camel-case consistently, the name should be getXMLParser() > (with upper-case P). > - Some toString() invocations are redundant because string > concatenation will call it automatically. > > I'll leave it to others to review the functionality correctness. > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-trac-ticket-862-TPS-rewrite-provide-connector-servic.patch Type: text/x-patch Size: 23186 bytes Desc: not available URL: From edewata at redhat.com Thu Mar 6 01:37:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Mar 2014 19:37:25 -0600 Subject: [Pki-devel] [PATCH] 0001-First-cut-at-Java-TPS-Buffer-class-and-APDU-class.patch In-Reply-To: <1680038252.27890900.1394043139592.JavaMail.zimbra@redhat.com> References: <1453808642.19836059.1393471325694.JavaMail.zimbra@redhat.com> <789040627.23766515.1393646418458.JavaMail.zimbra@redhat.com> <53160F34.6010407@redhat.com> <1931258818.26938185.1393972034881.JavaMail.zimbra@redhat.com> <53168EA6.7040309@redhat.com> <1680038252.27890900.1394043139592.JavaMail.zimbra@redhat.com> Message-ID: <5317D155.5090304@redhat.com> On 3/5/2014 12:12 PM, John Magne wrote: > ACKED by edewata,cfu. > > Pushed to master. It turns out the "*.class" that I suggested for the jar command was not working as expected and causing installation failure. Jack already pushed the fix to master. -- Endi S. Dewata From edewata at redhat.com Thu Mar 6 04:53:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Mar 2014 22:53:18 -0600 Subject: [Pki-devel] [PATCH] 416 Updated required RESTEasy version. Message-ID: <5317FF3E.6080603@redhat.com> The spec file has been modified to require RESTEasy to 3.0.6-2 which contains the required bug fixes. Ticket #554 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0416-Updated-required-RESTEasy-version.patch Type: text/x-patch Size: 1505 bytes Desc: not available URL: From edewata at redhat.com Thu Mar 6 05:03:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Mar 2014 23:03:25 -0600 Subject: [Pki-devel] [PATCH] 417 Replaced CLI wrapper with Python. Message-ID: <5318019D.3090702@redhat.com> The existing CLI wrapper script was written in Perl to call Java CLI. It has been replaced with a Python script that can call either the existing Java CLI or a not-yet-implemented Python CLI by specifying a --client-type parameter. This will allow testing the Python client library via CLI in the future. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0417-Replaced-CLI-wrapper-with-Python.patch Type: text/x-patch Size: 12653 bytes Desc: not available URL: From edewata at redhat.com Thu Mar 6 05:42:20 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Mar 2014 23:42:20 -0600 Subject: [Pki-devel] [PATCH] 416 Updated required RESTEasy version. In-Reply-To: <5317FF3E.6080603@redhat.com> References: <5317FF3E.6080603@redhat.com> Message-ID: <53180ABC.10909@redhat.com> On 3/5/2014 10:53 PM, Endi Sukma Dewata wrote: > The spec file has been modified to require RESTEasy to 3.0.6-2 which > contains the required bug fixes. > > Ticket #554 ACKed by Ade. Pushed to master. -- Endi S. Dewata From akoneru at redhat.com Thu Mar 6 14:37:24 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 06 Mar 2014 09:37:24 -0500 Subject: [Pki-devel] [PATCH] 84 Change the return type of retrieve_key(key_id, twsk) in KeyClient (python) In-Reply-To: <1394040873.2689.35.camel@aleeredhat.laptop> References: <1393853500.4195.3.camel@akoneru.redhat.com> <1394040873.2689.35.camel@aleeredhat.laptop> Message-ID: <1394116644.3439.4.camel@akoneru.redhat.com> Addressed Ade's comments. In addition to those, also committed a fix for the failing approve/reject/cancel request calls due to wrong connection.post method calls and added a catch to Test 2 in drmtest.py, since it will fail for a new instance. --Abhishek On Wed, 2014-03-05 at 12:34 -0500, Ade Lee wrote: > ACK - with the following caveats. > > 1. in key.py, add a blank line before # To store the unwrapped ... > 2. The logic in retrieve_key() can be condensed : > > if not key_provided: > unwrapped_key = self.crypto.symmetric_unwrap( > key_data.wrappedPrivateData, > session_key, > nonce_iv=key_data.nonceData) > key_data.private_data = unwrapped_key > return key_data > > 3. There is a test that has been added to the end of drmtest.py that > uses retrieve_key. It needs to be modified. > > Make sure to run through drmtest.py once again to confirm that it all works. > > Ade > > On Mon, 2014-03-03 at 08:31 -0500, Abhishek Koneru wrote: > > The initial return of type tuple [KeyData, unwrapped_key] is replaced by > > returning just the KeyData object. The unwrapped key will be set as > > attribute 'private_data' of the KeyData object. > > > > Please review the attached patch with the above mentioned changes. > > > > --Abhishek > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > From cfu at redhat.com Thu Mar 6 17:28:54 2014 From: cfu at redhat.com (Christina Fu) Date: Thu, 06 Mar 2014 09:28:54 -0800 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <5317BD5A.8050804@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> <5317BD5A.8050804@redhat.com> Message-ID: <5318B056.6070706@redhat.com> I decided to change the default for connector enable's to false instead of true so that the server can start even if no connectors are enabled. Attached please find the small patch. thanks, Christina On 03/05/2014 04:12 PM, Christina Fu wrote: > Hi, > First of all, thank you Endi for your through review. > > Per irc discussions, I have filed the following tickets: > * https://fedorahosted.org/pki/ticket/892 Need better error handling > for HttpConnection send() > - this ticket will address the comments irt pre-existing code > * https://fedorahosted.org/pki/ticket/893 subsystems (ca, kra, tks, > tps) mixed-up their subsystem certs when sharing same Tomcat instance > - this ticket will provide investigation for an issue I found irt > shared tomcat instance causing mixed-up subsystem certs among subsystems > > Attached please find the patch that addressed the remaining comments. > > thanks, > Christina > > On 03/04/2014 04:29 PM, Endi Sukma Dewata wrote: >> Some comments: >> >> 1. As discussed over IRC the common code HttpConnection shouldn't >> contain a subsystem-specific code, which in this case is setting the >> content type to application/x-www-form-urlencoded for TPS. >> >> 2. Also discussed over IRC, there's an existing issue with >> HttpConnection constructors: >> https://fedorahosted.org/pki/ticket/891 >> >> Suppose that issue is fixed later, it should be possible to merge the >> constructors. Then instead of calling different constructors for >> different timeout values like this: >> >> if (timeout == 0) { >> connector = >> new HttpConnector( >> null, nickname, remauthority, >> resendInterval, conf); >> } else { >> connector = >> new HttpConnector( >> null, nickname, remauthority, >> resendInterval, conf, timeout); >> } >> >> it can be simplified like this: >> >> connector = >> new HttpConnector( >> null, nickname, remauthority, >> resendInterval, conf, timeout); >> >> There's also a similar code in HttpConnFactory. >> >> 4. In HttpConnection the existing constructors were changed to pass >> "" as the default value of op. I think we should just pass a null >> value. This way the code can simply check the op like this: >> >> this(dest, factory, null); >> >> ... >> >> if (op == null) >> >> If we really want to accept an empty string, then probably we should >> normalize the string by trimming the white spaces before checking for >> empty string. >> >> 5. The HttpConnection.send() checks if the parameter is null or empty >> string then returns a null value with a comment "throw later". This >> error will only be detected later if another code tries to use the >> null return value, but at that point we're looking at a secondary >> issue, which makes it harder to troubleshoot. I think in general it's >> better to throw an exception as soon as the error is detected. >> >> 6. The HttpConnection.send() checks for untrusted certificate by >> checking the exception message. This may work now but could become >> inaccurate later due to translation, text changes, or typo. It would >> be better if there's a specific exception type or error code that we >> can check for this specific case. >> >> 7. Similar to #5, HttpConnection.send() swallows >> NumberFormatException. I think we should not catch this to detect the >> error as early as possible and also NumberFormatException is already >> a RuntimeException so it doesn't need to be wrapped/declared. >> >> 8. Similar to #5, the HttpConnector.send() (not HttpConnection) would >> swallow the exception so some errors wouldn't be detected >> immediately. I think the code could be simplified as follows (the >> send() already throws EBaseException): >> >> try { >> curConn = mConnFactory.getConn(op); >> return curConn.send(msg); >> >> } finally { >> if (curConn != null) { >> mConnFactory.returnConn(curConn); >> } >> } >> >> 9. Similar to #5, the ConnectionManager.getXMLparser() would swallow >> the exceptions. I think it would be better to wrap the exception in a >> RuntimeException and rethrow it. >> >> try { >> ByteArrayInputStream bis = >> new ByteArrayInputStream(text.getBytes()); >> return new XMLObject(bis); >> >> } catch (Exception e) { >> CMS.debug("TPSSubsystem: getXMLparser(): failed: "+ >> e.toString()); >> throw new RuntimeException(e); >> } >> >> We can change this code again in the future if necessary to use a >> more specific class or add the original exceptions into the throws list. >> >> 10. In ConnectionManager, the createConnector() will never return a >> null, so it's not necessary to check its return value in >> initConnectors(). It will simplify the code and some code analyzers >> like Coverity probably will report the part that handles the null >> case as dead code anyway. >> >> 11. Just some minor things: >> - The debug log in getXMLparser() should say "ConnectionManager" >> instead of "TPSSubsystem". >> - If we use camel-case consistently, the name should be >> getXMLParser() (with upper-case P). >> - Some toString() invocations are redundant because string >> concatenation will call it automatically. >> >> I'll leave it to others to review the functionality correctness. >> > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-trac-ticket-862-TPS-rewrite-provide-connector-servic.patch Type: text/x-patch Size: 2886 bytes Desc: not available URL: From alee at redhat.com Thu Mar 6 18:33:48 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 06 Mar 2014 13:33:48 -0500 Subject: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side In-Reply-To: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> References: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> Message-ID: <1394130828.19497.1.camel@aleeredhat.laptop> CryptoOperationStore(): On the python side, we created an abstract class CryptoUtil to encapsulate the crypto operations we wanted to provide. The idea here was that the client might want to use some crypto library other than JSS. In the main program for the client then - in the python case, its drmtest.py, the client would elect to instantiate the relevant subclass of CryptoUtil. The way you have it now, the KeyClient is hardcoded to use NSS. This is not what we want. Instead do this: Create a new abstract class - CryptoProvider. This will contain methods that we will call in KeyClient. Note that the CryptoProvider cannot contain static methods. Then create a NSSCryptoUtil class that implements the required methods, does init() etc. DRMTest should instantiate and pass the NSSCryptoUtil class into the KeyClient constructor. KeyClient: 1. Extra S in param_id description in getKeyInfo() - instead of KeyId object - something more descriptive like - key id for secret. This applies in many cases. 2. Many comments do not specify what the return is. 3. In generateKey(), you do not use transWrappedSession key - you should at least pass that parameter if it is provided. 4. archiveKey() - typo in comment clinetKeyId There is a sentence fragment -- To be implemented ... ? 5. archiveKey() - there are Java classes to deal with OIDs - and in fact, this particular OID is defined within JSS. You should use those classes, rather than : String algorithmOID = "{1 2 840 113549 3 7}"; 6. KeyRequestResponse 1. Needs a XMLAccessType(None) I may have further comments when the patch is resubmitted. Ade On Tue, 2014-03-04 at 20:13 -0500, Abhishek Koneru wrote: > Please review the attached patch which replicates the new python client's KeyClient class > on the Java side. > > --Abhishek. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Mar 6 20:36:35 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Mar 2014 14:36:35 -0600 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <5317BD5A.8050804@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> <5317BD5A.8050804@redhat.com> Message-ID: <5318DC53.9040106@redhat.com> On 3/5/2014 6:12 PM, Christina Fu wrote: > Hi, > First of all, thank you Endi for your through review. > > Per irc discussions, I have filed the following tickets: > * https://fedorahosted.org/pki/ticket/892 Need better error handling for > HttpConnection send() > - this ticket will address the comments irt pre-existing code > * https://fedorahosted.org/pki/ticket/893 subsystems (ca, kra, tks, tps) > mixed-up their subsystem certs when sharing same Tomcat instance > - this ticket will provide investigation for an issue I found irt > shared tomcat instance causing mixed-up subsystem certs among subsystems > > Attached please find the patch that addressed the remaining comments. > > thanks, > Christina Some additional comments: 12. As discussed over IRC, the empty string checking in HttpConnection.java:126 is unnecessary: if ((contentType != null) && (!contentType.equals(""))) { If we don't want an empty string to be a possible value, we probably should not accept it in the first place by adding this code in RemoteAuthority.java:59: if (contentType.equals("")) throw new IllegalArgumentException( "Content type cannot be empty"); 13. The code in HttpConnection.java:125-129 that sets the content type currently will only be executed if HttpConnection if op is not null. Is having a content type dependent on op being not null? The code probably can be changed like this: if (op == null) mHttpreq.setURI(mDest.getURI()); else mHttpreq.setURI(mDest.getURI(op)); // set content type regardless of op value String contentType = dest.getContentType(); if (contentType != null) { CMS.debug("HttpConnection: setting Content-Type"); mHttpreq.setHeader("Content-Type", contentType ); } 14. The above code that sets the content type currently only exists in the HttpConnection constructor that takes a timeout parameter. The other constructor that doesn't have a timeout parameter doesn't have this code (see line 81). This will lead to further divergence of the constructors. See https://fedorahosted.org/pki/ticket/891. I think until #891 is addressed we should make any changes consistent in all constructors. 15. In ConnectionManager.java:42, the HTTP_CONTENT_TYPE_APP_URLENCODED probably should be final & static since it's a constant. Or you can use this constant: http://docs.oracle.com/javaee/7/api/javax/ws/rs/core/MediaType.html#APPLICATION_FORM_URLENCODED 16. Since ConnectionManager will work in TPS only, the following comment probably can be removed. /* start is for resender only. no Resender for TPS conn.start(); */ That's it. ACK after addressing these issues. -- Endi S. Dewata From edewata at redhat.com Thu Mar 6 20:39:48 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Mar 2014 14:39:48 -0600 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <5318B056.6070706@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> <5317BD5A.8050804@redhat.com> <5318B056.6070706@redhat.com> Message-ID: <5318DD14.9080403@redhat.com> On 3/6/2014 11:28 AM, Christina Fu wrote: > I decided to change the default for connector enable's to false instead > of true so that the server can start even if no connectors are enabled. > > Attached please find the small patch. > > thanks, > Christina ACK. -- Endi S. Dewata From edewata at redhat.com Thu Mar 6 20:46:19 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Mar 2014 14:46:19 -0600 Subject: [Pki-devel] [PATCH] 415 Fixed CLI exceptions. In-Reply-To: <530E7731.4060305@redhat.com> References: <530E7731.4060305@redhat.com> Message-ID: <5318DE9B.2060409@redhat.com> On 2/26/2014 5:22 PM, Endi Sukma Dewata wrote: > Previously if the CLI requires SSL but the security database doesn't > exist it would throw an IOException. Now it has been replaced with an > Error. > > The exception handler also has been modified to generate better error > messages. > > Ticket #821 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Mar 6 20:46:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Mar 2014 14:46:28 -0600 Subject: [Pki-devel] [PATCH] 417 Replaced CLI wrapper with Python. In-Reply-To: <5318019D.3090702@redhat.com> References: <5318019D.3090702@redhat.com> Message-ID: <5318DEA4.4090504@redhat.com> On 3/5/2014 11:03 PM, Endi Sukma Dewata wrote: > The existing CLI wrapper script was written in Perl to call Java CLI. > It has been replaced with a Python script that can call either the > existing Java CLI or a not-yet-implemented Python CLI by specifying > a --client-type parameter. This will allow testing the Python client > library via CLI in the future. ACKed by Ade. Pushed to master. -- Endi S. Dewata From jmagne at redhat.com Fri Mar 7 01:20:47 2014 From: jmagne at redhat.com (John Magne) Date: Thu, 6 Mar 2014 20:20:47 -0500 (EST) Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <5318DD14.9080403@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> <5317BD5A.8050804@redhat.com> <5318B056.6070706@redhat.com> <5318DD14.9080403@redhat.com> Message-ID: <1531612659.29420154.1394155247092.JavaMail.zimbra@redhat.com> ACK: I looked over the original and all the subsequent patches. Functionality looks good. Just a couple of quesitons. 1. Should we have some nice defines in the java code to use that represent the various known "ops". 2. How about some simple sample code somewhere in there that demonstrates the use of this feature. Maybe just make a call to the TKS to get random data, and show the code to handle the response? ----- Original Message ----- From: "Endi Sukma Dewata" To: "Christina Fu" , pki-devel at redhat.com Sent: Thursday, March 6, 2014 12:39:48 PM Subject: Re: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem On 3/6/2014 11:28 AM, Christina Fu wrote: > I decided to change the default for connector enable's to false instead > of true so that the server can start even if no connectors are enabled. > > Attached please find the small patch. > > thanks, > Christina ACK. -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Fri Mar 7 01:38:54 2014 From: cfu at redhat.com (Christina Fu) Date: Thu, 06 Mar 2014 17:38:54 -0800 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <1531612659.29420154.1394155247092.JavaMail.zimbra@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> <5317BD5A.8050804@redhat.com> <5318B056.6070706@redhat.com> <5318DD14.9080403@redhat.com> <1531612659.29420154.1394155247092.JavaMail.zimbra@redhat.com> Message-ID: <5319232E.1090802@redhat.com> Hi jack, Thanks for the review! Please see response below: On 03/06/2014 05:20 PM, John Magne wrote: > ACK: > > I looked over the original and all the subsequent patches. > Functionality looks good. Just a couple of quesitons. > > 1. Should we have some nice defines in the java code to use that represent the various known "ops". Actually, these "ops" are admin-defined in the CS.cfg as explained in the comments of ConnectionManager.java (about line 63 and on) . I'd like to think of the callers being some kind of plugins that can be written so I think it might be better not to hard-code them. > > 2. How about some simple sample code somewhere in there that demonstrates the use of this feature. > Maybe just make a call to the TKS to get random data, and show the code to handle the response? Very valid request. In fact, I have a patch coming soon (If I can be allowed to check in this patch ;-) which will provide all the TKS remote requests sending and response parsing. It is for ticket #888, which I plan to submit in three batches, one for each remote subsystem, starting with TKS. When it comes, not only will you be able to see examples, you can just call these remote request handlers and get response all sorted out and parsed for you. > > ----- Original Message ----- > From: "Endi Sukma Dewata" > To: "Christina Fu" , pki-devel at redhat.com > Sent: Thursday, March 6, 2014 12:39:48 PM > Subject: Re: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem > > On 3/6/2014 11:28 AM, Christina Fu wrote: >> I decided to change the default for connector enable's to false instead >> of true so that the server can start even if no connectors are enabled. >> >> Attached please find the small patch. >> >> thanks, >> Christina > ACK. > From edewata at redhat.com Fri Mar 7 04:42:15 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Mar 2014 22:42:15 -0600 Subject: [Pki-devel] [PATCH] 839 Split pki manual page. Message-ID: <53194E27.6070404@redhat.com> The manual page for pki has been split into separate pages for each command module to simplify reading and editing. The formatting have been fixed to make it more consistent. The content of the manual pages will be further improved in future patches. Ticket #839 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0418-Split-pki-manual-page.patch Type: text/x-patch Size: 35532 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 7 15:51:15 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 09:51:15 -0600 Subject: [Pki-devel] [PATCH]418 Split pki manual page. In-Reply-To: <53194E27.6070404@redhat.com> References: <53194E27.6070404@redhat.com> Message-ID: <5319EAF3.9050701@redhat.com> Fixing the email subject line. It should have been patch #414. -- Endi S. Dewata On 3/6/2014 10:42 PM, Endi Sukma Dewata wrote: > The manual page for pki has been split into separate pages for each > command module to simplify reading and editing. The formatting have > been fixed to make it more consistent. The content of the manual > pages will be further improved in future patches. > > Ticket #839 From edewata at redhat.com Fri Mar 7 15:51:20 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 09:51:20 -0600 Subject: [Pki-devel] [PATCH] 419 Added CLI help command. Message-ID: <5319EAF8.1090407@redhat.com> A new help command has been added to display the manual page of the specified command. If the manual page doesn't exist it will try to display the manual page of the parent command. Ticket #519 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0419-Added-CLI-help-command.patch Type: text/x-patch Size: 4263 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 7 15:52:27 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 09:52:27 -0600 Subject: [Pki-devel] [PATCH] 420 Cleaned up CLI command list. Message-ID: <5319EB3B.1040502@redhat.com> The CLI help message has been simplified to show the commands as a single list. Ticket #839 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0420-Cleaned-up-CLI-command-list.patch Type: text/x-patch Size: 2844 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 7 20:02:24 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 14:02:24 -0600 Subject: [Pki-devel] [PATCH] 418 Split pki manual page. In-Reply-To: <5319EAF3.9050701@redhat.com> References: <53194E27.6070404@redhat.com> <5319EAF3.9050701@redhat.com> Message-ID: <531A25D0.1090006@redhat.com> On 3/7/2014 9:51 AM, Endi Sukma Dewata wrote: > Fixing the email subject line. It should have been patch #414. Fixing another mistake. It should have been patch #418. The file is in the original email titled "[PATCH] 839 Split pki manual page." -- Endi S. Dewata From cfu at redhat.com Fri Mar 7 23:22:27 2014 From: cfu at redhat.com (Christina Fu) Date: Fri, 07 Mar 2014 15:22:27 -0800 Subject: [Pki-devel] [PATCH] 414 Direct deployment for TPS. In-Reply-To: <531777D6.6070504@redhat.com> References: <530CFBED.60605@redhat.com> <531777D6.6070504@redhat.com> Message-ID: <531A54B3.1070001@redhat.com> Hi Endi, First of all, thanks for your patience on irc this morning. As you know, the pkispawn/installation area is new to me, so I try my best to understand what the issues are and what you are trying to fix. Here is a recap of some of my observations and suggestions. None are critical that need to be "fixed", but rather suggestions to add clarification. * MSStartServlet.java - Since it took me some time to investigate and figure out what "context", "subsystem", and "instanceDir" came from and resolved to. It might be a good idea to add comments right above the section explaining how they come to. - About removing destroy(), I am sure you have good reasons, but if you must "remove" it, may I suggest you comment it out and put explanation in comment there for my consumption later? Again, this part just doesn't seem relevant to the ticket, and I'd really like to focus on our tickets at hand. If we keep finding different things to go off and pursue, we will have a hard time reaching our immediate targets. In general, if it's unrelated, I prefer filing it off and attending to it later. Or, if others are finding themselves having cycle to look at this part for you, I'll let them do the research and ack for you. I wash my hands at this time ;-). * slot_substitution.py - This took you quite some time to explain to me too ;-). I think since the new TPS web.xml and velocity.properties do not contain any "slots", whether you skip the substitution or not doesn't make that much difference, so adding the code to single out TPS is ok, however, may I suggest that you add a little comment there explaining that there will be no need for substitution because slots are not allowed in the /user/share or something to that effect? I just worry later when we need to get back to this we don't remember why (I'm sure you will, but maybe for my sake). * I also asked if this patch will affect stand-alone tomcat-TPS and you said no. It's basically an ACK if it tested to work. Again, adding clarity in comments are just suggestions. thanks, Christina On 03/05/2014 11:15 AM, Endi Sukma Dewata wrote: > New patch attached. Fixed a problem creating symlinks. > > > > _______________________________________________ > 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 edewata at redhat.com Fri Mar 7 23:39:14 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 17:39:14 -0600 Subject: [Pki-devel] [PATCH] 418 Split pki manual page. In-Reply-To: <531A25D0.1090006@redhat.com> References: <53194E27.6070404@redhat.com> <5319EAF3.9050701@redhat.com> <531A25D0.1090006@redhat.com> Message-ID: <531A58A2.3050509@redhat.com> On 3/7/2014 2:02 PM, Endi Sukma Dewata wrote: > On 3/7/2014 9:51 AM, Endi Sukma Dewata wrote: >> Fixing the email subject line. It should have been patch #414. > > Fixing another mistake. It should have been patch #418. The file is in > the original email titled "[PATCH] 839 Split pki manual page." ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Mar 7 23:39:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 17:39:18 -0600 Subject: [Pki-devel] [PATCH] 419 Added CLI help command. In-Reply-To: <5319EAF8.1090407@redhat.com> References: <5319EAF8.1090407@redhat.com> Message-ID: <531A58A6.3050609@redhat.com> On 3/7/2014 9:51 AM, Endi Sukma Dewata wrote: > A new help command has been added to display the manual page of the > specified command. If the manual page doesn't exist it will try to > display the manual page of the parent command. > > Ticket #519 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Mar 7 23:39:21 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 17:39:21 -0600 Subject: [Pki-devel] [PATCH] 420 Cleaned up CLI command list. In-Reply-To: <5319EB3B.1040502@redhat.com> References: <5319EB3B.1040502@redhat.com> Message-ID: <531A58A9.1050604@redhat.com> On 3/7/2014 9:52 AM, Endi Sukma Dewata wrote: > The CLI help message has been simplified to show the commands as > a single list. > > Ticket #839 ACKed by Jack. Pushed to master. -- Endi S. Dewata From mharmsen at redhat.com Sat Mar 8 02:48:46 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 07 Mar 2014 18:48:46 -0800 Subject: [Pki-devel] [PATCH] TRAC Ticket #868 - REST API get certs links missing segment [20140307] Message-ID: <531A850E.2010707@redhat.com> Please review the following patch which addresses: * PKI TRAC Ticket #868 - REST API get certs links missing segment This patch has been tested on the DOGTAG_10_0_BRANCH as used on Fedora 19: Prior to the patch, the following URL: * https://fedora19.example.com:8443/ca/rest/certs produces an XML page which contains XML such as: * which produces an 'HTTP Status 404' page. After the patch has been applied, the same URL produces an XML page which contains XML such as: * which corresponds to a valid URL. NOTE: This patch needs to be applied to the DOGTAG_10_0_BRANCH (Fedora 19), the DOGTAG_10_1_BRANCH (Fedora 20), and the master (Fedora 21+). This patch may also need to be applied to the IPA_V3_RHEL_7_ERRATA_BRANCH. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20140307-REST-API-get-certs-links-missing-segment.patch Type: text/x-patch Size: 1664 bytes Desc: not available URL: From edewata at redhat.com Sat Mar 8 03:53:47 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 21:53:47 -0600 Subject: [Pki-devel] [PATCH] 414 Direct deployment for TPS. In-Reply-To: <531A54B3.1070001@redhat.com> References: <530CFBED.60605@redhat.com> <531777D6.6070504@redhat.com> <531A54B3.1070001@redhat.com> Message-ID: <531A944B.1010908@redhat.com> On 3/7/2014 5:22 PM, Christina Fu wrote: > Hi Endi, > > First of all, thanks for your patience on irc this morning. As you > know, the pkispawn/installation area is new to me, so I try my best to > understand what the issues are and what you are trying to fix. Thanks for your review. I think this is a good exercise to familiarize (or re-familiarize) ourselves with various aspects of Tomcat and the deployment process which indeed is quite complex. This patch is part of an effort to simplify the process, as you saw by the reduction of the deployment code for TPS (and eventually for other subsystems too). > Here is a recap of some of my observations and suggestions. None are > critical that need to be "fixed", but rather suggestions to add > clarification. > > * MSStartServlet.java > - Since it took me some time to investigate and figure out what > "context", "subsystem", and "instanceDir" came from and resolved to. It > might be a good idea to add comments right above the section explaining > how they come to. I added some comments in the updated patch. > - About removing destroy(), I am sure you have good reasons, but if > you must "remove" it, may I suggest you comment it out and put > explanation in comment there for my consumption later? Again, this part > just doesn't seem relevant to the ticket, and I'd really like to focus > on our tickets at hand. If we keep finding different things to go off > and pursue, we will have a hard time reaching our immediate targets. In > general, if it's unrelated, I prefer filing it off and attending to it > later. Or, if others are finding themselves having cycle to look at > this part for you, I'll let them do the research and ack for you. I > wash my hands at this time ;-). I originally thought this was a straight forward clean up. I've created a separate ticket for this: https://fedorahosted.org/pki/ticket/896 It has a link to the source code that we discussed. > * slot_substitution.py > - This took you quite some time to explain to me too ;-). I think > since the new TPS web.xml and velocity.properties do not contain any > "slots", whether you skip the substitution or not doesn't make that much > difference, so adding the code to single out TPS is ok, however, may I > suggest that you add a little comment there explaining that there will > be no need for substitution because slots are not allowed in the > /user/share or something to that effect? I just worry later when we > need to get back to this we don't remember why (I'm sure you will, but > maybe for my sake). It's not just unnecessary, but the pki_target_subsystem_web_xml and pki_target_velocity_properties now point to non-existent paths because we're no longer copy the TPS files into those locations in the instance, so this code cannot be executed for TPS. I've added some comments in the code. if deployer.master_dict['pki_subsystem'] != "TPS": deployer.file.apply_slot_substitution( deployer.master_dict['pki_target_velocity_properties']) deployer.file.apply_slot_substitution( deployer.master_dict['pki_target_subsystem_web_xml']) > * I also asked if this patch will affect stand-alone tomcat-TPS and you > said no. Since currently stand-alone TPS for Tomcat doesn't work we cannot really verify this. But so far I don't see anything specific that would prevent that from working. > It's basically an ACK if it tested to work. Again, adding clarity in > comments are just suggestions. Yes, I have installed TPS and tested it with the CLI and UI. > thanks, > Christina Thanks. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 8 03:54:07 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 07 Mar 2014 21:54:07 -0600 Subject: [Pki-devel] [PATCH] 421 Removed redundant GenericServlet.destroy() invocation. Message-ID: <531A945F.5040406@redhat.com> The CMSStartServlet has been modified to remove the code that calls GenericServlet.destroy() because it is an empty default implementation which was intended to provide convenience for writing servlets. Ticket #896 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0421-Removed-redundant-GenericServlet.destroy-invocation.patch Type: text/x-patch Size: 1145 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 10 22:42:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Mar 2014 17:42:37 -0500 Subject: [Pki-devel] [PATCH] 422 Added login page for TPS UI. Message-ID: <531E3FDD.9000706@redhat.com> The TPS UI has been modified to provide an unprotected front page. The main TPS UI has been moved into a protected area. The front page provides a login button which when clicked will ask the user to authenticate with the client certificate. If the authentication is successful, the main page will appear. There is also a logout link on the upper right corner of the main page. When clicked it will destroy both the client and server sessions. Ticket #846 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0422-Added-login-page-for-TPS-UI.patch Type: text/x-patch Size: 14439 bytes Desc: not available URL: From edewata at redhat.com Tue Mar 11 02:08:06 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Mar 2014 21:08:06 -0500 Subject: [Pki-devel] [PATCH] 423 Removed config path from web.xml. Message-ID: <531E7006.4070600@redhat.com> Previously the CMSStartServlet always requires a cfgPath parameter pointing to the CS.cfg location. By default the parameter points to /conf//CS.cfg unless it's manually changed by the admin after installation. Recently the servlet has been modified such that if the parameter is not specified it will generate the default path automatically. So it is no longer necessary to keep the cfgPath parameter in the web.xml templates because it will point to the same location. This patch removes the cfgPath parameters from all web.xml templates. This way newly created subsystems will not have this parameter, which will help direct deployment in the future. An upgrade script has been added to remove the parameter from existing instances if it points to the default location. If the parameter points to a different location that means the subsystem has been customized so it will not be changed. Ticket #748, #499 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0423-Removed-config-path-from-web.xml.patch Type: text/x-patch Size: 8364 bytes Desc: not available URL: From cfu at redhat.com Tue Mar 11 17:35:29 2014 From: cfu at redhat.com (Christina Fu) Date: Tue, 11 Mar 2014 10:35:29 -0700 Subject: [Pki-devel] [PATCH] 422 Added login page for TPS UI. In-Reply-To: <531E3FDD.9000706@redhat.com> References: <531E3FDD.9000706@redhat.com> Message-ID: <531F4961.5060301@redhat.com> Hi Endi, First of all, thank you for your patience on the irc. Here is a summary of my comments/questions: * I asked if the login/logout thing can be applied to the other subsystems agent interface - you said yes. I filed a separate ticket to do later: https://fedorahosted.org/pki/ticket/902 - Login & logout link/page for CA, KRA, OCSP, TKS * I asked whether the logout() event can be signalled into the cs service so the event can be audited. You pondered on some idea, but I put a note in the new ticket so we can look at later. * I asked if window.crypto.logout stuff works for IE as well (we are required to support IE, as I understand it)? - I did a quick search and it seems like IE does not support it, but you can do the following: document.execCommand('ClearAuthenticationCache'); If the research is going to take a long time, then feel free to file a separate ticket to take care of it later. Otherwise, please make sure IE is supported. * I asked where the roles under * are checked. - you explained to me that its checked under ACLInterceptor, where the list of roles is obtained using PKIRealm which takes acl.properties in for the resource/action acl mapping, and which correctly used the same underlying group/user framework that's used by the pre-existing non-rest servlets. * I asked why does not need xxx definition in the web.xml - You explained that because you have a fallback authenticator called SSLAuthenticatorWithFallback (specified in tps-tomcat/shared/conf/Catalina/localhost/tps.xml) which looks into auth-method.properties to check for correct authentication method for each op. Since the first two items are already captured in the new ticket, I think only the 3rd item needs to be considered for either immediate addressing or filing for a new ticket. It's up to you. That's all I have. thanks, Christina On 03/10/2014 03:42 PM, Endi Sukma Dewata wrote: > The TPS UI has been modified to provide an unprotected front page. > The main TPS UI has been moved into a protected area. The front > page provides a login button which when clicked will ask the user > to authenticate with the client certificate. If the authentication > is successful, the main page will appear. There is also a logout > link on the upper right corner of the main page. When clicked it > will destroy both the client and server sessions. > > Ticket #846 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Mar 12 01:27:48 2014 From: jmagne at redhat.com (John Magne) Date: Tue, 11 Mar 2014 21:27:48 -0400 (EDT) Subject: [Pki-devel] [PATCH] 422 Added login page for TPS UI. In-Reply-To: <531F4961.5060301@redhat.com> References: <531E3FDD.9000706@redhat.com> <531F4961.5060301@redhat.com> Message-ID: <1697103077.33002161.1394587668374.JavaMail.zimbra@redhat.com> What cfu said applies. As for the window.crypto.logout, yes that won't work in IE. Might also want to check to see if window.cryto exists before calling it? Also sounds like to audit log logout as cfu suggested would we not need some support on the back end? At this point it might be reasonable to pursue logging out the user from the server side. Othewise if tested to work this seems nice enough to ACK for now. ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, March 11, 2014 10:35:29 AM > Subject: Re: [Pki-devel] [PATCH] 422 Added login page for TPS UI. > > Hi Endi, > First of all, thank you for your patience on the irc. > > Here is a summary of my comments/questions: > * I asked if the login/logout thing can be applied to the other subsystems > agent interface > - you said yes. I filed a separate ticket to do later: > https://fedorahosted.org/pki/ticket/902 - Login & logout link/page for CA, > KRA, OCSP, TKS > > * I asked whether the logout() event can be signalled into the cs service so > the event can be audited. You pondered on some idea, but I put a note in the > new ticket so we can look at later. > > * I asked if window.crypto.logout stuff works for IE as well (we are required > to support IE, as I understand it)? > - I did a quick search and it seems like IE does not support it, but you can > do the following: > document.execCommand('ClearAuthenticationCache'); > If the research is going to take a long time, then feel free to file a > separate ticket to take care of it later. Otherwise, please make sure IE is > supported. > > * I asked where the roles under * are checked. > - you explained to me that its checked under ACLInterceptor, where the list > of roles is obtained using PKIRealm which takes acl.properties in for the > resource/action acl mapping, and which correctly used the same underlying > group/user framework that's used by the pre-existing non-rest servlets. > > * I asked why does not need xxx > definition in the web.xml > - You explained that because you have a fallback authenticator called > SSLAuthenticatorWithFallback (specified in > tps-tomcat/shared/conf/Catalina/localhost/tps.xml) which looks into > auth-method.properties to check for correct authentication method for each > op. > > Since the first two items are already captured in the new ticket, I think > only the 3rd item needs to be considered for either immediate addressing or > filing for a new ticket. It's up to you. > > That's all I have. > thanks, > Christina > > On 03/10/2014 03:42 PM, Endi Sukma Dewata wrote: > > > The TPS UI has been modified to provide an unprotected front page. > The main TPS UI has been moved into a protected area. The front > page provides a login button which when clicked will ask the user > to authenticate with the client certificate. If the authentication > is successful, the main page will appear. There is also a logout > link on the upper right corner of the main page. When clicked it > will destroy both the client and server sessions. > > Ticket #846 > > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Wed Mar 12 02:13:48 2014 From: cfu at redhat.com (Christina Fu) Date: Tue, 11 Mar 2014 19:13:48 -0700 Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) Message-ID: <531FC2DC.90404@redhat.com> This is a request for review for the attached patch. The patch is the first part for https://fedorahosted.org/pki/ticket/888 - TPS rewrite: provide remote authority functions This patch provides functions for TKS: - computeSessionKey - createKeySetData - encryptData - computeRandomData Two things to note: * Because of code not yet available, only computeRandomData() was tested. Other functions can be tested/adusted when the needed info are available. * Because we don't know where the tps profile name will be at this point, computeSessionKey currently has a hard-coded entry in there. It is noted in a TODO comment. Again, this will be adjusted when it's more clear where it comes from. thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ticket-888-TPS-rewrite-provide-remote-authority-func.patch Type: text/x-patch Size: 24194 bytes Desc: not available URL: From cfu at redhat.com Wed Mar 12 03:14:37 2014 From: cfu at redhat.com (Christina Fu) Date: Tue, 11 Mar 2014 20:14:37 -0700 Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) In-Reply-To: <531FC2DC.90404@redhat.com> References: <531FC2DC.90404@redhat.com> Message-ID: <531FD11D.7020406@redhat.com> Attached please find comments to the functions. Christina On 03/11/2014 07:13 PM, Christina Fu wrote: > This is a request for review for the attached patch. > The patch is the first part for > https://fedorahosted.org/pki/ticket/888 - TPS rewrite: provide remote > authority functions > > This patch provides functions for TKS: > - computeSessionKey > - createKeySetData > - encryptData > - computeRandomData > > Two things to note: > * Because of code not yet available, only computeRandomData() was > tested. Other functions can be tested/adusted when the needed info > are available. > * Because we don't know where the tps profile name will be at this > point, computeSessionKey currently has a hard-coded entry in there. It > is noted in a TODO comment. Again, this will be adjusted when it's > more clear where it comes from. > > thanks, > Christina > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ticket-888-part1-TKS-comments.patch Type: text/x-patch Size: 4231 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 12 04:32:24 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 11 Mar 2014 23:32:24 -0500 Subject: [Pki-devel] [PATCH] 424 Fixed javadoc issues. Message-ID: <531FE358.5010002@redhat.com> Due to recent changes the javadoc command was missing some packages and a new dependency. This patch fixes the command to include the missing com.netscape.cms and the new org.dogtagpki packages. It's also adding the missing RESTEasy client library into the classpath. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0424-Fixed-javadoc-issues.patch Type: text/x-patch Size: 1870 bytes Desc: not available URL: From akoneru at redhat.com Wed Mar 12 16:11:27 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 12 Mar 2014 12:11:27 -0400 Subject: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side In-Reply-To: <1394130828.19497.1.camel@aleeredhat.laptop> References: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> <1394130828.19497.1.camel@aleeredhat.laptop> Message-ID: <1394640687.23670.7.camel@akoneru.redhat.com> Please review the patch which addresses the comments below. > CryptoOperationStore(): > On the python side, we created an abstract class CryptoUtil to > encapsulate the crypto operations we wanted to provide. The idea here > was that the client might want to use some crypto library other than > JSS. In the main program for the client then - in the python case, its > drmtest.py, the client would elect to instantiate the relevant subclass > of CryptoUtil. > > The way you have it now, the KeyClient is hardcoded to use NSS. This is > not what we want. Instead do this: > > Create a new abstract class - CryptoProvider. This will contain methods > that we will call in KeyClient. Note that the CryptoProvider cannot > contain static methods. Then create a NSSCryptoUtil class that > implements the required methods, does init() etc. > > DRMTest should instantiate and pass the NSSCryptoUtil class into the > KeyClient constructor. > Created classes CryptoProvider and NSSCryptoProvider in base/common/src/com/netscape/certsrv/util. An NSSCrypto provider object is passed in PKIClient object that stores information about configuration and connection. Since PKIClient is passed to KeyClient it can access the CryptoProvider object from there. The reason for adding CryptoProvider in PKIClient is that it can be used in future for all kinds of crypto operations to be done in any client. > KeyClient: > 1. Extra S in param_id description in getKeyInfo() - instead of KeyId > object - something more descriptive like - key id for secret. This > applies in many cases. > 2. Many comments do not specify what the return is. > 3. In generateKey(), you do not use transWrappedSession key - you should > at least pass that parameter if it is provided. > 4. archiveKey() - typo in comment clinetKeyId > There is a sentence fragment -- To be implemented ... ? > 5. archiveKey() - there are Java classes to deal with OIDs - and in > fact, this particular OID is defined within JSS. You should use those > classes, rather than : > String algorithmOID = "{1 2 840 113549 3 7}"; > 6. > > KeyRequestResponse > 1. Needs a XMLAccessType(None) Addressed all the comments except for 5. Did not find a way to get the OID from the algorithm name in the JSS packages. Added it as a static final variable in KeyRequestResource. > > I may have further comments when the patch is resubmitted. > > Ade > > On Tue, 2014-03-04 at 20:13 -0500, Abhishek Koneru wrote: > > Please review the attached patch which replicates the new python client's KeyClient class > > on the Java side. > > > > --Abhishek. > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-86-2-Changes-to-KeyClient-on-the-java-side.patch Type: text/x-patch Size: 87273 bytes Desc: not available URL: From akoneru at redhat.com Wed Mar 12 17:54:07 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 12 Mar 2014 13:54:07 -0400 (EDT) Subject: [Pki-devel] [PATCH] 86-2 Addressed comments for patch 86 In-Reply-To: <1394640687.23670.7.camel@akoneru.redhat.com> References: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> <1394130828.19497.1.camel@aleeredhat.laptop> <1394640687.23670.7.camel@akoneru.redhat.com> Message-ID: <459644204.9334947.1394646847761.JavaMail.zimbra@redhat.com> Please ignore the previous patch. Removed some unnecessary code. --Abhishek ----- Original Message ----- From: "Abhishek Koneru" To: alee at redhat.com Cc: "pki-devel" Sent: Wednesday, March 12, 2014 12:11:27 PM Subject: Re: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side Please review the patch which addresses the comments below. > CryptoOperationStore(): > On the python side, we created an abstract class CryptoUtil to > encapsulate the crypto operations we wanted to provide. The idea here > was that the client might want to use some crypto library other than > JSS. In the main program for the client then - in the python case, its > drmtest.py, the client would elect to instantiate the relevant subclass > of CryptoUtil. > > The way you have it now, the KeyClient is hardcoded to use NSS. This is > not what we want. Instead do this: > > Create a new abstract class - CryptoProvider. This will contain methods > that we will call in KeyClient. Note that the CryptoProvider cannot > contain static methods. Then create a NSSCryptoUtil class that > implements the required methods, does init() etc. > > DRMTest should instantiate and pass the NSSCryptoUtil class into the > KeyClient constructor. > Created classes CryptoProvider and NSSCryptoProvider in base/common/src/com/netscape/certsrv/util. An NSSCrypto provider object is passed in PKIClient object that stores information about configuration and connection. Since PKIClient is passed to KeyClient it can access the CryptoProvider object from there. The reason for adding CryptoProvider in PKIClient is that it can be used in future for all kinds of crypto operations to be done in any client. > KeyClient: > 1. Extra S in param_id description in getKeyInfo() - instead of KeyId > object - something more descriptive like - key id for secret. This > applies in many cases. > 2. Many comments do not specify what the return is. > 3. In generateKey(), you do not use transWrappedSession key - you should > at least pass that parameter if it is provided. > 4. archiveKey() - typo in comment clinetKeyId > There is a sentence fragment -- To be implemented ... ? > 5. archiveKey() - there are Java classes to deal with OIDs - and in > fact, this particular OID is defined within JSS. You should use those > classes, rather than : > String algorithmOID = "{1 2 840 113549 3 7}"; > 6. > > KeyRequestResponse > 1. Needs a XMLAccessType(None) Addressed all the comments except for 5. Did not find a way to get the OID from the algorithm name in the JSS packages. Added it as a static final variable in KeyRequestResource. > > I may have further comments when the patch is resubmitted. > > Ade > > On Tue, 2014-03-04 at 20:13 -0500, Abhishek Koneru wrote: > > Please review the attached patch which replicates the new python client's KeyClient class > > on the Java side. > > > > --Abhishek. > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > --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-86-2-Changes-to-KeyClient-on-the-java-side.patch Type: text/x-patch Size: 85567 bytes Desc: not available URL: From cfu at redhat.com Wed Mar 12 19:27:42 2014 From: cfu at redhat.com (Christina Fu) Date: Wed, 12 Mar 2014 12:27:42 -0700 Subject: [Pki-devel] [PATCH] 424 Fixed javadoc issues. In-Reply-To: <531FE358.5010002@redhat.com> References: <531FE358.5010002@redhat.com> Message-ID: <5320B52E.2010809@redhat.com> Endi, I applied that patch but still got some errors: /usr/bin/cmake -E cmake_progress_report /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/build/CMakeFiles ^M [100%] Built target pki-silent-jar^M /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/base/server/cms/src/com/netscape/cms/servlet/base/CMSStartServlet.java:32: error: package com.netscape.cms.tomcat does not exist^M import com.netscape.cms.tomcat.ProxyRealm; Constructing Javadoc information...^M /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/base/server/cms/src/com/netscape/cms/servlet/base/CMSStartServlet.java:32: error: package com.netscape.cms.tomcat does not exist^M import com.netscape.cms.tomcat.ProxyRealm; Am I missing something? Christina On 03/11/2014 09:32 PM, Endi Sukma Dewata wrote: > Due to recent changes the javadoc command was missing some packages > and a new dependency. This patch fixes the command to include the > missing com.netscape.cms and the new org.dogtagpki packages. It's > also adding the missing RESTEasy client library into the classpath. > > > > _______________________________________________ > 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 mharmsen at redhat.com Thu Mar 13 02:25:53 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 12 Mar 2014 19:25:53 -0700 Subject: [Pki-devel] TRAC Ticket #869 - f19 ipa-server-install fails at step 6/22 of cert sys install - systemctl start pki-tomcatd.target fails Message-ID: <53211731.1090001@redhat.com> Please review the following patch which addresses: * PKI TRAC Ticket #869 - f19 ipa-server-install fails at step 6/22 of cert sys install - systemctl start pki-tomcatd.target fails This patch has been tested on Dogtag 10.0 on Fedora 19 using packages built from the DOGTAG_10_0_BRANCH. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20140312-Added-daemon-reload-method.patch Type: text/x-patch Size: 2643 bytes Desc: not available URL: From alee at redhat.com Thu Mar 13 14:13:30 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Mar 2014 10:13:30 -0400 Subject: [Pki-devel] DRM authentication discussion (preliminary design) Message-ID: <1394720010.4459.4.camel@localhost.localdomain> I've written up a very high level design based on what we discussed yesterday. Please provide comments so we can flesh it out further. http://pki.fedoraproject.org/wiki/Enhancing_DRM_Authentication_and_Authorization Thanks, Ade From edewata at redhat.com Thu Mar 13 15:16:52 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Mar 2014 10:16:52 -0500 Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) In-Reply-To: <531FC2DC.90404@redhat.com> References: <531FC2DC.90404@redhat.com> Message-ID: <5321CBE4.7040806@redhat.com> On 3/11/2014 9:13 PM, Christina Fu wrote: > This is a request for review for the attached patch. > The patch is the first part for https://fedorahosted.org/pki/ticket/888 > - TPS rewrite: provide remote authority functions > > This patch provides functions for TKS: > - computeSessionKey > - createKeySetData > - encryptData > - computeRandomData > > Two things to note: > * Because of code not yet available, only computeRandomData() was > tested. Other functions can be tested/adusted when the needed info are > available. > * Because we don't know where the tps profile name will be at this > point, computeSessionKey currently has a hard-coded entry in there. It > is noted in a TODO comment. Again, this will be adjusted when it's more > clear where it comes from. > > thanks, > Christina Some comments: 1. In RemoteRequestHandler.parserResponse() now if the content is null the method will return null too. I suppose content should never be null, so this is an error case. As I mentioned in the previous review, if an error is detected, it would be better to throw an exception instead of returning null so that it can be traced to the actual error. if (content == null) { throw new EBaseException("RemoteRequestHandler: parserResponse(): no response content."); } On the other hand, if null content is considered a valid input (meaning empty content), it would be better to return an empty hashtable so the caller doesn't need to worry about null hashtable: Hashtable vars = new Hashtable(); if (content == null) { return vars; } 2. In RemoteRequestHandler.parserResponse() it's not necessary to create a new string nvs from string e: for (String e : elements) { String nvs = new String(e); String[] nv = nvs.split(NAME_VALUE_EQUAL); ... } Java strings are immutable and the split() will create new strings, so the original content won't be affected. The code can be simplified as follows: for (String nvs : elements) { String[] nv = nvs.split(NAME_VALUE_EQUAL); ... } 3. In RemoteRequestHandler.parserResponse() the following null checking is unnecessary because split() doesn't return null string elements. String[] nv = nvs.split(NAME_VALUE_EQUAL); if (nv[0] != null && nv[1] != null) { vars.put(nv[0], nv[1]); } Instead, we should check whether the array contains 2 elements. What should we do if it contains more, or less, than 2 elements? if (nv.length == 2) { vars.put(nv[0], nv[1]); } else { // throw error, skip, or ignore the extra elements? } 4. Since both the name and the value are strings, RemoteRequestHandler.parserResponse() can actually return a Hashtable so it's not necessary to downcast the values into string again later. 5. Similar to #1, in TKSRemoteRequestHandler.computeSessionKey() if the TKS response is null it's an error case, so it should throw an exception instead of returning null again. Also note the extra parentheses in the if-statement can be removed. String content = resp.getContent(); if (content != null && !content.equals("")) { ... } else { throw new EBaseException("TKSRemoteRequestHandler: computeSessionKey(): no response content."); } 6. Regardless of #1, the following null response checking in TKSRemoteRequestHandler.computeSessionKey() is unnecessary because the response will never be null since parseResponse() will never receive a null content: if (content != null && !content.equals("")) { // content can't be null Hashtable response = parseResponse(content); // response can't be null if (response == null) { CMS.debug("TKSRemoteRequestHandler: computeSessionKey(): parseResponse returned null."); return null; } 7. Similar to #1, if missing status is considered an error then it should throw an exception: String value = response.get(TKS_RESPONSE_STATUS); if (value == null) { throw new EBaseException("TKSRemoteRequestHandler: computeSessionKey(): Bad TKS Connection. Please make sure TKS is accessible by TPS."); } else { CMS.debug("TKSRemoteRequestHandler: computeSessionKey(): got status =" + value); } 8. The computeSessionKey() now returns a hashtable containing attributes, so someone calling this method will have to check the docs to make sure he/she uses the right attributes and casts the values to the right types. It would be better to define a class for the return value: CreateSessionKeyResponse response = tksReq.computeSessionKey(...); String status = response.getStatus(); byte[] sessionKey = response.getSessionKey(); 9. Comments #5-#8 also apply to createKeySetData(), computeRandomData(), and encryptData(). -- Endi S. Dewata From alee at redhat.com Thu Mar 13 17:03:26 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Mar 2014 13:03:26 -0400 Subject: [Pki-devel] [PATCH] 86-2 Addressed comments for patch 86 In-Reply-To: <459644204.9334947.1394646847761.JavaMail.zimbra@redhat.com> References: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> <1394130828.19497.1.camel@aleeredhat.laptop> <1394640687.23670.7.camel@akoneru.redhat.com> <459644204.9334947.1394646847761.JavaMail.zimbra@redhat.com> Message-ID: <1394730206.4459.31.camel@localhost.localdomain> In KeyClient: 1. setTransportCert() should have a javadoc explaining exactly what is in this variable (the base64 cert sans header and footer?) 2. Do we have something specifying the valid status values to be set in modifyKeyStatus()? If so, we should probably add a check for that in modifyKeyStatus() 3. retrieveKey() can be simplified. Unlike python, where we cannot overload methods, we can do so on the Java side. Separate into retrieveKey(keyId) and retrieveKey(keyId, transWrappedSessionKey) This will simplify the documentation too. 4. A similar simplification can be done for retrieveKeyByPassphrase() 5. Fix algorithm OID. 6. NSSCryptoProvider: * In initialize(), remove TODO comment. * generateSessionKey(algorithm?). The purpose of this method is to return a symmetric key that is valid for wrapping/ unwrapping the DRM. Right now, we support only one algorithm -- 168 bit DES3 keys. So this method should not include an algorithm as a parameter. The whole point of this method is that the user need not know what the algorithm is. * generateSymmetricKey() has no length parameters. This is not generic enough - some algorithms require length parameters. See the python code. * the methods should have a check for whether the object is initialized and if not - initialize. This will prevent null pointer exceptions in case someone fails to initialize first. * getKeyGenAlgorithm() and getEncryptionAlgorithm() should not return defaults if the argument passed in is wrong. They should throw an exception. You return the default if the value passed in is null. 7. There was code added to the Python side to set up an NSS database for the user if one did not already exist, and import the transport cert. Much of that is pretty useful, but has not been added to the Java side. 8. Please confirm that all the new functions in KeyClient are exercised in the DRMTest. On Wed, 2014-03-12 at 13:54 -0400, Abhishek Koneru wrote: > Please ignore the previous patch. Removed some unnecessary code. > > --Abhishek > > ----- Original Message ----- > From: "Abhishek Koneru" > To: alee at redhat.com > Cc: "pki-devel" > Sent: Wednesday, March 12, 2014 12:11:27 PM > Subject: Re: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side > > Please review the patch which addresses the comments below. > > CryptoOperationStore(): > > On the python side, we created an abstract class CryptoUtil to > > encapsulate the crypto operations we wanted to provide. The idea here > > was that the client might want to use some crypto library other than > > JSS. In the main program for the client then - in the python case, its > > drmtest.py, the client would elect to instantiate the relevant subclass > > of CryptoUtil. > > > > The way you have it now, the KeyClient is hardcoded to use NSS. This is > > not what we want. Instead do this: > > > > Create a new abstract class - CryptoProvider. This will contain methods > > that we will call in KeyClient. Note that the CryptoProvider cannot > > contain static methods. Then create a NSSCryptoUtil class that > > implements the required methods, does init() etc. > > > > DRMTest should instantiate and pass the NSSCryptoUtil class into the > > KeyClient constructor. > > > Created classes CryptoProvider and NSSCryptoProvider in > base/common/src/com/netscape/certsrv/util. An NSSCrypto provider object > is passed in PKIClient object that stores information about > configuration and connection. Since PKIClient is passed to KeyClient it > can access the CryptoProvider object from there. The reason for adding > CryptoProvider in PKIClient is that it can be used in future for all > kinds of crypto operations to be done in any client. > > KeyClient: > > 1. Extra S in param_id description in getKeyInfo() - instead of KeyId > > object - something more descriptive like - key id for secret. This > > applies in many cases. > > 2. Many comments do not specify what the return is. > > 3. In generateKey(), you do not use transWrappedSession key - you should > > at least pass that parameter if it is provided. > > 4. archiveKey() - typo in comment clinetKeyId > > There is a sentence fragment -- To be implemented ... ? > > 5. archiveKey() - there are Java classes to deal with OIDs - and in > > fact, this particular OID is defined within JSS. You should use those > > classes, rather than : > > String algorithmOID = "{1 2 840 113549 3 7}"; > > 6. > > > > KeyRequestResponse > > 1. Needs a XMLAccessType(None) > > Addressed all the comments except for 5. Did not find a way to get the > OID from the algorithm name in the JSS packages. Added it as a static > final variable in KeyRequestResource. > > > > I may have further comments when the patch is resubmitted. > > > > Ade > > > > On Tue, 2014-03-04 at 20:13 -0500, Abhishek Koneru wrote: > > > Please review the attached patch which replicates the new python client's KeyClient class > > > on the Java side. > > > > > > --Abhishek. > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > --Abhishek > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Mar 13 17:22:29 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Mar 2014 13:22:29 -0400 Subject: [Pki-devel] TRAC Ticket #869 - f19 ipa-server-install fails at step 6/22 of cert sys install - systemctl start pki-tomcatd.target fails In-Reply-To: <53211731.1090001@redhat.com> References: <53211731.1090001@redhat.com> Message-ID: <1394731349.4459.34.camel@localhost.localdomain> In general, the patch is fine. Note that in the 10.1+, we have modified the code to pass an array of commands to the system call. Make sure to do that on those branches. ACK. On Wed, 2014-03-12 at 19:25 -0700, Matthew Harmsen wrote: > Please review the following patch which addresses: > * PKI TRAC Ticket #869 - f19 ipa-server-install fails at step > 6/22 of cert sys install - systemctl start pki-tomcatd.target > fails > > This patch has been tested on Dogtag 10.0 on Fedora 19 using packages > built from the DOGTAG_10_0_BRANCH. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Mar 13 17:34:58 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Mar 2014 13:34:58 -0400 Subject: [Pki-devel] TRAC Ticket #869 - f19 ipa-server-install fails at step 6/22 of cert sys install - systemctl start pki-tomcatd.target fails In-Reply-To: <1394731349.4459.34.camel@localhost.localdomain> References: <53211731.1090001@redhat.com> <1394731349.4459.34.camel@localhost.localdomain> Message-ID: <1394732098.4459.39.camel@localhost.localdomain> Also, I think we should be trying to clean up pylint warnings as we go through and not add any new ones. That means for instance, that the new method you added should contain a docstring class. In fact, I would suggest making some changes to fix most of the pylint warnings in say the Systemd class. There aren't that many - and if everyone does it, we can slowly improve the code as we go. If you want to do this only in master, thats fine with me too. Ade On Thu, 2014-03-13 at 13:22 -0400, Ade Lee wrote: > In general, the patch is fine. Note that in the 10.1+, we have modified > the code to pass an array of commands to the system call. Make sure to > do that on those branches. > > ACK. > > On Wed, 2014-03-12 at 19:25 -0700, Matthew Harmsen wrote: > > Please review the following patch which addresses: > > * PKI TRAC Ticket #869 - f19 ipa-server-install fails at step > > 6/22 of cert sys install - systemctl start pki-tomcatd.target > > fails > > > > This patch has been tested on Dogtag 10.0 on Fedora 19 using packages > > built from the DOGTAG_10_0_BRANCH. > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Mar 13 18:38:48 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Mar 2014 14:38:48 -0400 Subject: [Pki-devel] [PATCH] TRAC Ticket #868 - REST API get certs links missing segment [20140307] In-Reply-To: <531A850E.2010707@redhat.com> References: <531A850E.2010707@redhat.com> Message-ID: <1394735928.4459.43.camel@localhost.localdomain> This patch doesn't future proof against other possible URL changes. This bug basically arose because we changed the annotation for CertsResource from "/certs" to "". I think you should be rather mapping to the relevant GET method instead using: http://docs.oracle.com/javaee/6/api/javax/ws/rs/core/UriBuilder.html#path%28java.lang.Class,%20java.lang.String%29 either: public abstract UriBuilder path(java.lang.Class resource, java.lang.String method) or: public abstract UriBuilder path(java.lang.reflect.Method method) In fact, we might want to open a ticket to confirm that all the rest of the URLs are likewise future-proofed against changes. Ade On Fri, 2014-03-07 at 18:48 -0800, Matthew Harmsen wrote: > Please review the following patch which addresses: > * PKI TRAC Ticket #868 - REST API get certs links missing > segment > > This patch has been tested on the DOGTAG_10_0_BRANCH as used on Fedora > 19: > > > Prior to the patch, the following URL: > > > * https://fedora19.example.com:8443/ca/rest/certs > > produces an XML page which contains XML such as: > > > * href="https://fedora19.example.com:8443/ca/rest/0x1" > rel="self"/> > > which produces an 'HTTP Status 404' page. > > > > After the patch has been applied, the same URL produces an XML > page which contains XML such as: > > > * href="https://fedora19.example.com:8443/ca/rest/certs/0x1" rel="self"/> > > which corresponds to a valid URL. > > > > NOTE: This patch needs to be applied to the DOGTAG_10_0_BRANCH > (Fedora 19), the DOGTAG_10_1_BRANCH (Fedora 20), and the master > (Fedora 21+). > This patch may also need to be applied to the > IPA_V3_RHEL_7_ERRATA_BRANCH. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From bj2917 at att.com Thu Mar 13 14:52:44 2014 From: bj2917 at att.com (JACKSON, BOYD R) Date: Thu, 13 Mar 2014 14:52:44 +0000 Subject: [Pki-devel] Dogtag 10.1 User Documentation? Message-ID: <437DF6598A45C74A9B7144CAC99165D108FDF656@mokscy3msgusr9o.itservices.sbc.com> Greetings all, Does anyone on this mailing list know of any resources I could use that would show me the steps required to generate certificates using Dogtag 10.1? I have all of the Dogtag 10.1 components installed but looking for some insight on how to create, issue and manage client certificates that will be used for client authentication. The server that will be contacted has a Verisign issued certificate. Boyd Jackson AT&T Government Solutions Cell- 703-314-9173 Fax- 212-202-5261 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Thu Mar 13 18:52:19 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 13 Mar 2014 14:52:19 -0400 Subject: [Pki-devel] [Pki-users] Dogtag 10.1 User Documentation? In-Reply-To: <437DF6598A45C74A9B7144CAC99165D108FDF656@mokscy3msgusr9o.itservices.sbc.com> References: <437DF6598A45C74A9B7144CAC99165D108FDF656@mokscy3msgusr9o.itservices.sbc.com> Message-ID: <1394736739.4459.49.camel@localhost.localdomain> There are several resources available. First of all, the Red Hat Certificate System documentation (for all the old interfaces) still applies. Look at the EE and agent guides. https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/ For the new REST interfaces, some documentation is provided on the wiki. We're working to improve this documentation - but what have is here: http://pki.fedoraproject.org/wiki/CLI http://pki.fedoraproject.org/wiki/RESTEasy http://pki.fedoraproject.org/wiki/REST If you need help with REST, ask here or get onto #dogtag-pki on freenode. Ade On Thu, 2014-03-13 at 14:52 +0000, JACKSON, BOYD R wrote: > Greetings all, > > > > Does anyone on this mailing list know of any resources I could use > that would show me the steps required to generate certificates using > Dogtag 10.1? I have all of the Dogtag 10.1 components installed but > looking for some insight on how to create, issue and manage client > certificates that will be used for client authentication. The server > that will be contacted has a Verisign issued certificate. > > > > Boyd Jackson > > AT&T Government Solutions > > Cell- 703-314-9173 > > Fax- 212-202-5261 > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From edewata at redhat.com Thu Mar 13 19:00:17 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Mar 2014 14:00:17 -0500 Subject: [Pki-devel] [PATCH] 422 Added login page for TPS UI. In-Reply-To: <531F4961.5060301@redhat.com> References: <531E3FDD.9000706@redhat.com> <531F4961.5060301@redhat.com> Message-ID: <53220041.800@redhat.com> On 3/11/2014 12:35 PM, Christina Fu wrote: > * I asked if window.crypto.logout stuff works for IE as well (we are > required to support IE, as I understand it)? > - I did a quick search and it seems like IE does not support it, but > you can do the following: > document.execCommand('ClearAuthenticationCache'); > If the research is going to take a long time, then feel free to file > a separate ticket to take care of it later. Otherwise, please make sure > IE is supported. I opened this ticket for IE support because we might need some browser detection mechanism and proper tests: https://fedorahosted.org/pki/ticket/903 On 3/11/2014 8:27 PM, John Magne wrote: > What cfu said applies. > > As for the window.crypto.logout, yes that won't work in IE. Might > also want to check to see if window.cryto exists before calling it? I added a code to check window.cryto. > Also sounds like to audit log logout as cfu suggested would we not > need some support on the back end? At this point it might be > reasonable to pursue logging out the user from the server side. Ideally the client would logout from the server, but sometimes the client would just close the connection without logging out. I added a possible way to detect such case in the following ticket: https://fedorahosted.org/pki/ticket/902 > Othewise if tested to work this seems nice enough to ACK for now. This patch has been tested on Firefox. Pushed to master. Thanks all. -- Endi S. Dewata From edewata at redhat.com Thu Mar 13 21:27:29 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Mar 2014 16:27:29 -0500 Subject: [Pki-devel] [PATCH] 424 Fixed javadoc issues. In-Reply-To: <5320B52E.2010809@redhat.com> References: <531FE358.5010002@redhat.com> <5320B52E.2010809@redhat.com> Message-ID: <532222C1.2040808@redhat.com> On 3/12/2014 2:27 PM, Christina Fu wrote: > Endi, > > I applied that patch but still got some errors: > > /usr/bin/cmake -E cmake_progress_report > /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/build/CMakeFiles ^M > [100%] Built target pki-silent-jar^M > /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/base/server/cms/src/com/netscape/cms/servlet/base/CMSStartServlet.java:32: > error: package com.netscape.cms.tomcat does not exist^M > import com.netscape.cms.tomcat.ProxyRealm; > > Constructing Javadoc information...^M > /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/base/server/cms/src/com/netscape/cms/servlet/base/CMSStartServlet.java:32: > error: package com.netscape.cms.tomcat does not exist^M > import com.netscape.cms.tomcat.ProxyRealm; > > Am I missing something? > > Christina OK, looks like there's another missing dependency. Please try the attached patch. Thanks. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0424-1-Fixed-javadoc-issues.patch Type: text/x-patch Size: 2278 bytes Desc: not available URL: From jmagne at redhat.com Thu Mar 13 23:29:17 2014 From: jmagne at redhat.com (John Magne) Date: Thu, 13 Mar 2014 19:29:17 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0004- Further work on TPS Processor, format operation.patch In-Reply-To: <1193685716.35496863.1394752792040.JavaMail.zimbra@redhat.com> Message-ID: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> Ticket #895 https://fedorahosted.org/pki/ticket/895 Further work on TPS Processor, format operation. This patch gets a bit farther on the TPS format operation, just before applet upgrade, which will also need secure channel functionality. Also, patch provides some misc clean up and functionality. 1. Method to calculate the token type. 2. Some added convenience methods to get various config params for the Format operation. 3. More progress for the format operation up until we attempt to upgrade the applet. 4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client. --- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Further-work-on-TPS-Processor-format-operation.patch Type: text/x-patch Size: 35000 bytes Desc: not available URL: From cfu at redhat.com Fri Mar 14 15:09:11 2014 From: cfu at redhat.com (Christina Fu) Date: Fri, 14 Mar 2014 08:09:11 -0700 Subject: [Pki-devel] [PATCH] 424 Fixed javadoc issues. In-Reply-To: <532222C1.2040808@redhat.com> References: <531FE358.5010002@redhat.com> <5320B52E.2010809@redhat.com> <532222C1.2040808@redhat.com> Message-ID: <53231B97.1080605@redhat.com> That did it, Endi. Thank you! ACK Christina On 03/13/2014 02:27 PM, Endi Sukma Dewata wrote: > On 3/12/2014 2:27 PM, Christina Fu wrote: >> Endi, >> >> I applied that patch but still got some errors: >> >> /usr/bin/cmake -E cmake_progress_report >> /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/build/CMakeFiles >> ^M >> [100%] Built target pki-silent-jar^M >> /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/base/server/cms/src/com/netscape/cms/servlet/base/CMSStartServlet.java:32: >> >> error: package com.netscape.cms.tomcat does not exist^M >> import com.netscape.cms.tomcat.ProxyRealm; >> >> Constructing Javadoc information...^M >> /home/cfu/work/src/dt10d/packages/BUILD/pki-core-10.2.0/base/server/cms/src/com/netscape/cms/servlet/base/CMSStartServlet.java:32: >> >> error: package com.netscape.cms.tomcat does not exist^M >> import com.netscape.cms.tomcat.ProxyRealm; >> >> Am I missing something? >> >> Christina > > OK, looks like there's another missing dependency. Please try the > attached patch. Thanks. > From edewata at redhat.com Fri Mar 14 15:30:39 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Mar 2014 10:30:39 -0500 Subject: [Pki-devel] [PATCH] 425 Added remove button handler for TPS UI. Message-ID: <5323209F.4000009@redhat.com> The Table class has been modified to handle the remove button. When the button is clicked, it will get the list of items selected for deletion. If there is nothing selected it will not do anything. If there are some items selected, it will display the list in a dialog box and ask the user to confirm the deletion. If the operation is confirmed, the items will be deleted one by one. The table will be refreshed after the process is done. In some pages the buttons have been updated to reflect the availability of the add/remove operations for the corresponding REST resources. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0425-Added-remove-button-handler-for-TPS-UI.patch Type: text/x-patch Size: 8075 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 14 16:05:40 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Mar 2014 11:05:40 -0500 Subject: [Pki-devel] [PATCH] 424 Fixed javadoc issues. In-Reply-To: <53231B97.1080605@redhat.com> References: <531FE358.5010002@redhat.com> <5320B52E.2010809@redhat.com> <532222C1.2040808@redhat.com> <53231B97.1080605@redhat.com> Message-ID: <532328D4.9080909@redhat.com> On 3/14/2014 10:09 AM, Christina Fu wrote: > That did it, Endi. > > Thank you! > ACK > > Christina Pushed to master. Thanks. -- Endi S. Dewata From cfu at redhat.com Fri Mar 14 18:42:43 2014 From: cfu at redhat.com (Christina Fu) Date: Fri, 14 Mar 2014 11:42:43 -0700 Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) In-Reply-To: <5321CBE4.7040806@redhat.com> References: <531FC2DC.90404@redhat.com> <5321CBE4.7040806@redhat.com> Message-ID: <53234DA3.3040001@redhat.com> Thank you Endi and Jack for your comments. Attached please find the patch that addressed your comments. thanks, Christina On 03/13/2014 08:16 AM, Endi Sukma Dewata wrote: > On 3/11/2014 9:13 PM, Christina Fu wrote: >> This is a request for review for the attached patch. >> The patch is the first part for https://fedorahosted.org/pki/ticket/888 >> - TPS rewrite: provide remote authority functions >> >> This patch provides functions for TKS: >> - computeSessionKey >> - createKeySetData >> - encryptData >> - computeRandomData >> >> Two things to note: >> * Because of code not yet available, only computeRandomData() was >> tested. Other functions can be tested/adusted when the needed info are >> available. >> * Because we don't know where the tps profile name will be at this >> point, computeSessionKey currently has a hard-coded entry in there. It >> is noted in a TODO comment. Again, this will be adjusted when it's more >> clear where it comes from. >> >> thanks, >> Christina > > Some comments: > > 1. In RemoteRequestHandler.parserResponse() now if the content is null > the method will return null too. I suppose content should never be > null, so this is an error case. As I mentioned in the previous review, > if an error is detected, it would be better to throw an exception > instead of returning null so that it can be traced to the actual error. > > if (content == null) { > throw new EBaseException("RemoteRequestHandler: > parserResponse(): no response content."); > } > > On the other hand, if null content is considered a valid input > (meaning empty content), it would be better to return an empty > hashtable so the caller doesn't need to worry about null hashtable: > > Hashtable vars = new Hashtable(); > if (content == null) { > return vars; > } > > 2. In RemoteRequestHandler.parserResponse() it's not necessary to > create a new string nvs from string e: > > for (String e : elements) { > String nvs = new String(e); > String[] nv = nvs.split(NAME_VALUE_EQUAL); > ... > } > > Java strings are immutable and the split() will create new strings, so > the original content won't be affected. The code can be simplified as > follows: > > for (String nvs : elements) { > String[] nv = nvs.split(NAME_VALUE_EQUAL); > ... > } > > 3. In RemoteRequestHandler.parserResponse() the following null > checking is unnecessary because split() doesn't return null string > elements. > > String[] nv = nvs.split(NAME_VALUE_EQUAL); > if (nv[0] != null && nv[1] != null) { > vars.put(nv[0], nv[1]); > } > > Instead, we should check whether the array contains 2 elements. What > should we do if it contains more, or less, than 2 elements? > > if (nv.length == 2) { > vars.put(nv[0], nv[1]); > } else { > // throw error, skip, or ignore the extra elements? > } > > 4. Since both the name and the value are strings, > RemoteRequestHandler.parserResponse() can actually return a > Hashtable so it's not necessary to downcast the values > into string again later. > > 5. Similar to #1, in TKSRemoteRequestHandler.computeSessionKey() if > the TKS response is null it's an error case, so it should throw an > exception instead of returning null again. Also note the extra > parentheses in the if-statement can be removed. > > String content = resp.getContent(); > > if (content != null && !content.equals("")) { > ... > > } else { > throw new EBaseException("TKSRemoteRequestHandler: > computeSessionKey(): no response content."); > } > > 6. Regardless of #1, the following null response checking in > TKSRemoteRequestHandler.computeSessionKey() is unnecessary because the > response will never be null since parseResponse() will never receive a > null content: > > if (content != null && !content.equals("")) { > > // content can't be null > Hashtable response = > parseResponse(content); > > // response can't be null > if (response == null) { > CMS.debug("TKSRemoteRequestHandler: computeSessionKey(): > parseResponse returned null."); > return null; > } > > 7. Similar to #1, if missing status is considered an error then it > should throw an exception: > > String value = response.get(TKS_RESPONSE_STATUS); > if (value == null) { > throw new EBaseException("TKSRemoteRequestHandler: > computeSessionKey(): Bad TKS Connection. Please make sure TKS is > accessible by TPS."); > > } else { > CMS.debug("TKSRemoteRequestHandler: computeSessionKey(): got > status =" + value); > } > > 8. The computeSessionKey() now returns a hashtable containing > attributes, so someone calling this method will have to check the docs > to make sure he/she uses the right attributes and casts the values to > the right types. It would be better to define a class for the return > value: > > CreateSessionKeyResponse response = tksReq.computeSessionKey(...); > String status = response.getStatus(); > byte[] sessionKey = response.getSessionKey(); > > 9. Comments #5-#8 also apply to createKeySetData(), > computeRandomData(), and encryptData(). > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ticket-888-part-1-TKS-TPS-rewrite-provide-remote-aut.patch Type: text/x-patch Size: 54056 bytes Desc: not available URL: From cfu at redhat.com Fri Mar 14 23:27:36 2014 From: cfu at redhat.com (Christina Fu) Date: Fri, 14 Mar 2014 16:27:36 -0700 Subject: [Pki-devel] DRM authentication discussion (preliminary design) In-Reply-To: <1394720010.4459.4.camel@localhost.localdomain> References: <1394720010.4459.4.camel@localhost.localdomain> Message-ID: <53239068.5030107@redhat.com> Ade, I think the high-level design captured most of what we discussed that day. One thing I'd like to propose is that since all subsystems, including the now being rewritten Tomcat TPS, share the same authentication and authorization plugin framework, I hope your design/implementaton is not limited to DRM. Therefore I hope the new context ldap attribute is to be added to all the agent-managed data records (certs, requests, key records, etc.). Also, even though the use case that triggered this design was due to support for different applications, internally within a CS system, it is just some kind of "security scope", and we do want to support deployments where the same application is used but multiple "security scopes" are defined (e.g. ipa1, ipa2, pkiuser1, pkiuser2, etc.),. Therefore, instead of calling it "application", I'd suggest that we think of it as a "scope" or something like that, and name them appropriately in code and documentation. Also, we did talk about the ability to assign multiple groups to the same user. I expect the existing authentication and authorization framework to be used (with modification, if necessary). In this case, I have a question. That is, how do you efficiently identify the scope that the user intends to manage? Perhaps we need to allow agents to specify their scope in the uri so that the backend knows which scope to authenticate/authorize? Would we then allow same id across different scopes? About what you suggested in the CS.cfg regarding allowing multiple authentication dbs. Is the following what you have in mind? First, the java cs subsystems has a framework for both the authentication and authorization plugins. e.g. auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents auths.instance.AgentCertAuth.pluginName=AgentCertAuth where each plugin defines its own set of required config params. So, with the example auth dbs definitions in CS.cfg that you provided on the wiki, We could now then add something like auths.instance.AgentCertAuth.authdb=ipa ? BTW, back to what I suggested on not using the word application, I'd suggest the following scope definitions instead: SecurityScope.contexts=pkiuser,barbican,ipa,dnssec,... SecurityScope.default=pkiuser SecurityScope.ipa.authdb.hostname=... SecurityScope,ipa.authdb,port=... etc So the new auths parameter would be something like this instead: auths.instance.AgentCertAuth.SecurityScope=ipa I assume the authentication and authorization db will always be the same, whichever the authentication scope points to? I will await your detailed design with much anticipation. Christina On 03/13/2014 07:13 AM, Ade Lee wrote: > I've written up a very high level design based on what we discussed > yesterday. Please provide comments so we can flesh it out further. > > http://pki.fedoraproject.org/wiki/Enhancing_DRM_Authentication_and_Authorization > > Thanks, > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Sat Mar 15 01:13:09 2014 From: jmagne at redhat.com (John Magne) Date: Fri, 14 Mar 2014 21:13:09 -0400 (EDT) Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) In-Reply-To: <53234DA3.3040001@redhat.com> References: <531FC2DC.90404@redhat.com> <5321CBE4.7040806@redhat.com> <53234DA3.3040001@redhat.com> Message-ID: <42643243.1259.1394845989016.JavaMail.zimbra@redhat.com> ACK: This is for the new classes that give clients easy access to the data and the status of requests sent to the TKS. This will help me nicely when negotiating the secure channel protocol. When I start using it and determine a new need, I'll just add it in a separate ticket at the time. ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Friday, March 14, 2014 11:42:43 AM Subject: Re: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) Thank you Endi and Jack for your comments. Attached please find the patch that addressed your comments. thanks, Christina On 03/13/2014 08:16 AM, Endi Sukma Dewata wrote: > On 3/11/2014 9:13 PM, Christina Fu wrote: >> This is a request for review for the attached patch. >> The patch is the first part for https://fedorahosted.org/pki/ticket/888 >> - TPS rewrite: provide remote authority functions >> >> This patch provides functions for TKS: >> - computeSessionKey >> - createKeySetData >> - encryptData >> - computeRandomData >> >> Two things to note: >> * Because of code not yet available, only computeRandomData() was >> tested. Other functions can be tested/adusted when the needed info are >> available. >> * Because we don't know where the tps profile name will be at this >> point, computeSessionKey currently has a hard-coded entry in there. It >> is noted in a TODO comment. Again, this will be adjusted when it's more >> clear where it comes from. >> >> thanks, >> Christina > > Some comments: > > 1. In RemoteRequestHandler.parserResponse() now if the content is null > the method will return null too. I suppose content should never be > null, so this is an error case. As I mentioned in the previous review, > if an error is detected, it would be better to throw an exception > instead of returning null so that it can be traced to the actual error. > > if (content == null) { > throw new EBaseException("RemoteRequestHandler: > parserResponse(): no response content."); > } > > On the other hand, if null content is considered a valid input > (meaning empty content), it would be better to return an empty > hashtable so the caller doesn't need to worry about null hashtable: > > Hashtable vars = new Hashtable(); > if (content == null) { > return vars; > } > > 2. In RemoteRequestHandler.parserResponse() it's not necessary to > create a new string nvs from string e: > > for (String e : elements) { > String nvs = new String(e); > String[] nv = nvs.split(NAME_VALUE_EQUAL); > ... > } > > Java strings are immutable and the split() will create new strings, so > the original content won't be affected. The code can be simplified as > follows: > > for (String nvs : elements) { > String[] nv = nvs.split(NAME_VALUE_EQUAL); > ... > } > > 3. In RemoteRequestHandler.parserResponse() the following null > checking is unnecessary because split() doesn't return null string > elements. > > String[] nv = nvs.split(NAME_VALUE_EQUAL); > if (nv[0] != null && nv[1] != null) { > vars.put(nv[0], nv[1]); > } > > Instead, we should check whether the array contains 2 elements. What > should we do if it contains more, or less, than 2 elements? > > if (nv.length == 2) { > vars.put(nv[0], nv[1]); > } else { > // throw error, skip, or ignore the extra elements? > } > > 4. Since both the name and the value are strings, > RemoteRequestHandler.parserResponse() can actually return a > Hashtable so it's not necessary to downcast the values > into string again later. > > 5. Similar to #1, in TKSRemoteRequestHandler.computeSessionKey() if > the TKS response is null it's an error case, so it should throw an > exception instead of returning null again. Also note the extra > parentheses in the if-statement can be removed. > > String content = resp.getContent(); > > if (content != null && !content.equals("")) { > ... > > } else { > throw new EBaseException("TKSRemoteRequestHandler: > computeSessionKey(): no response content."); > } > > 6. Regardless of #1, the following null response checking in > TKSRemoteRequestHandler.computeSessionKey() is unnecessary because the > response will never be null since parseResponse() will never receive a > null content: > > if (content != null && !content.equals("")) { > > // content can't be null > Hashtable response = > parseResponse(content); > > // response can't be null > if (response == null) { > CMS.debug("TKSRemoteRequestHandler: computeSessionKey(): > parseResponse returned null."); > return null; > } > > 7. Similar to #1, if missing status is considered an error then it > should throw an exception: > > String value = response.get(TKS_RESPONSE_STATUS); > if (value == null) { > throw new EBaseException("TKSRemoteRequestHandler: > computeSessionKey(): Bad TKS Connection. Please make sure TKS is > accessible by TPS."); > > } else { > CMS.debug("TKSRemoteRequestHandler: computeSessionKey(): got > status =" + value); > } > > 8. The computeSessionKey() now returns a hashtable containing > attributes, so someone calling this method will have to check the docs > to make sure he/she uses the right attributes and casts the values to > the right types. It would be better to define a class for the return > value: > > CreateSessionKeyResponse response = tksReq.computeSessionKey(...); > String status = response.getStatus(); > byte[] sessionKey = response.getSessionKey(); > > 9. Comments #5-#8 also apply to createKeySetData(), > computeRandomData(), and encryptData(). > _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Sat Mar 15 02:10:22 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 14 Mar 2014 19:10:22 -0700 Subject: [Pki-devel] [PATCH] TRAC Ticket #868 - REST API get certs links missing segment [20140307] In-Reply-To: <1394735928.4459.43.camel@localhost.localdomain> References: <531A850E.2010707@redhat.com> <1394735928.4459.43.camel@localhost.localdomain> Message-ID: <5323B68E.7010906@redhat.com> On 03/13/14 11:38, Ade Lee wrote: > This patch doesn't future proof against other possible URL changes. > This bug basically arose because we changed the annotation for > CertsResource from "/certs" to "". Ade, While I understand your concern about not "future proofing" against other URL changes, I am confused by your statement that '... we changed the annotation for CertsResource from "/certs" to "".' All *CertResource.java*(presuming "CertsResource.java" is a typo?) files currently contain "/certs" as a part of their annotations: * DOGTAG_10_0_BRANCH (Fedora 19 - this ticket): o ./base/common/src/com/netscape/certsrv/cert/CertResource.java + all annotations utilize "certs/{id}", not just "{id}" o ./base/server/cms/src/com/netscape/cms/servlet/cert/CertService.java + currently specifies "{id}" instead of "certs/{id}" which yields the 404 error: # URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(certId.toHexString()); # URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(id.toHexString()); * DOGTAG_10_1_BRANCH (Fedora 20) o ./base/common/src/com/netscape/certsrv/cert/CertResource.java + all annotations utilize "certs/{id}", not just "{id}" o ./base/server/cms/src/com/netscape/cms/servlet/cert/CertService.java + currently specifies "{id}" instead of "certs/{id}" which yields the 404 error: # URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(certId.toHexString()); # URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(id.toHexString()); * master (Fedora 21+) o ./base/common/src/com/netscape/certsrv/cert/CertResource.java + all annotations utilize "certs/{id}", not just "{id}" o ./base/ca/src/org/dogtagpki/server/ca/rest/CertService.java + currently specifies "{id}" instead of "certs/{id}" which yields the 404 error: # URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(certId.toHexString()); # URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(id.toHexString()); Are you requesting that we change *CertResource.java*to remove all of the "/certs" prefixes from the annotations instead of changing the *CertService.java*implementations? Or, based upon your pastebin: uriInfo.getBaseUriBuilder() .path(ShowsResource.class, "getShow") .build(show.getId()); @Path("shows") public class ShowsResource { @GET @Path("{showId}") public String getShow ( @PathParam("showId") long showId) { return "HAHAHAHA"; } } Generates: "context-root/45" Instead of "context-root/shows/45" are you are trying to introduce a new class (e. g. - *ShowsResource.java*) which extends all of the other Resource classes so that implementation Service classes such as *CertService.java*will call *ShowsResource.class*instead of their *CertResource.class*directly? I presume that this interim class would provide an unchanging interface to all of the underlying Resource classes (but perhaps its annotations might need to change whenever an underlying Resource changes)? To fix the immediate bug, could we simply check in my change to the various branches and create a ticket for this work? Presuming that the other two tickets ( PKI TRAC Ticket #728 - null pointer exception thrown when processing 501 from dogtag 9-> 10 instance and PKI TRAC Ticket #802 - Tomcat running as root ) do not need to be fixed at this time, this would allow us to proceed with getting the Dogtag 10.0.7 builds finalized so that I can move on to the more pressing Dogtag 10.1.1 issue. Thanks, -- Matt > I think you should be rather mapping to the relevant GET method instead > using: > > http://docs.oracle.com/javaee/6/api/javax/ws/rs/core/UriBuilder.html#path%28java.lang.Class,%20java.lang.String%29 > > either: > public abstract UriBuilder path(java.lang.Class resource, > java.lang.String method) > > or: > public abstract UriBuilder path(java.lang.reflect.Method method) > > In fact, we might want to open a ticket to confirm that all the rest of > the URLs are likewise future-proofed against changes. > > Ade > > On Fri, 2014-03-07 at 18:48 -0800, Matthew Harmsen wrote: >> Please review the following patch which addresses: >> * PKI TRAC Ticket #868 - REST API get certs links missing >> segment >> >> This patch has been tested on the DOGTAG_10_0_BRANCH as used on Fedora >> 19: >> >> >> Prior to the patch, the following URL: >> >> >> * https://fedora19.example.com:8443/ca/rest/certs >> >> produces an XML page which contains XML such as: >> >> >> * > href="https://fedora19.example.com:8443/ca/rest/0x1" >> rel="self"/> >> >> which produces an 'HTTP Status 404' page. >> >> >> >> After the patch has been applied, the same URL produces an XML >> page which contains XML such as: >> >> >> * > href="https://fedora19.example.com:8443/ca/rest/certs/0x1" rel="self"/> >> >> which corresponds to a valid URL. >> >> >> >> NOTE: This patch needs to be applied to the DOGTAG_10_0_BRANCH >> (Fedora 19), the DOGTAG_10_1_BRANCH (Fedora 20), and the master >> (Fedora 21+). >> This patch may also need to be applied to the >> IPA_V3_RHEL_7_ERRATA_BRANCH. >> >> >> _______________________________________________ >> 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 Mar 17 13:29:27 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 17 Mar 2014 09:29:27 -0400 Subject: [Pki-devel] [PATCH] TRAC Ticket #868 - REST API get certs links missing segment [20140307] In-Reply-To: <5323B68E.7010906@redhat.com> References: <531A850E.2010707@redhat.com> <1394735928.4459.43.camel@localhost.localdomain> <5323B68E.7010906@redhat.com> Message-ID: <1395062967.7659.12.camel@aleeredhat.laptop> On Fri, 2014-03-14 at 19:10 -0700, Matthew Harmsen wrote: > On 03/13/14 11:38, Ade Lee wrote: > > > This patch doesn't future proof against other possible URL changes. > > This bug basically arose because we changed the annotation for > > CertsResource from "/certs" to "". > Ade, > > While I understand your concern about not "future proofing" against > other URL changes, I am confused by your statement that '... we > changed the annotation for CertsResource from "/certs" to "".' > > All CertResource.java (presuming "CertsResource.java" is a typo?) > files currently contain "/certs" as a part of their annotations: > * DOGTAG_10_0_BRANCH (Fedora 19 - this ticket): > * ./base/common/src/com/netscape/certsrv/cert/CertResource.java > * all annotations utilize "certs/{id}", not just > "{id}" > * ./base/server/cms/src/com/netscape/cms/servlet/cert/CertService.java > * currently specifies "{id}" instead of > "certs/{id}" which yields the 404 error: > * URI uri = > uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(certId.toHexString()); > * URI uri = > uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(id.toHexString()); Matt, my point is that the above code used to work because the top-level annotation in CertResource.java used to be "certs". At that time, then, the annotation for getCert() would have been "{id}", and the above formulation in CertService.java would have resulted in a correct result. It was however, not the best way of formulating the result. In fact, we see that it broke as soon as we modified the top level annotation from "certs" to "", and instead moved the annotation into the individual method. A better way to do this would have been to rather refer to the annotation of the specific method directly, rather than trying to build it from the top annotation - something like this: URI uri = uriInfo.getBaseUriBuilder().path(CertResource.class, "getCert").build(certId.toHexString()); All I was trying to show in the pastebin was an example of building the URI by referencing the specific method in the resource. Ade > * DOGTAG_10_1_BRANCH (Fedora 20) > * ./base/common/src/com/netscape/certsrv/cert/CertResource.java > * all annotations utilize "certs/{id}", not just > "{id}" > * ./base/server/cms/src/com/netscape/cms/servlet/cert/CertService.java > * currently specifies "{id}" instead of > "certs/{id}" which yields the 404 error: > * URI uri = > uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(certId.toHexString()); > * URI uri = > uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(id.toHexString()); > * master (Fedora 21+) > * ./base/common/src/com/netscape/certsrv/cert/CertResource.java > * all annotations utilize "certs/{id}", not just > "{id}" > * ./base/ca/src/org/dogtagpki/server/ca/rest/CertService.java > * currently specifies "{id}" instead of > "certs/{id}" which yields the 404 error: > * URI uri = > uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(certId.toHexString()); > * URI uri = > uriInfo.getBaseUriBuilder().path(CertResource.class).path("{id}").build(id.toHexString()); > > Are you requesting that we change CertResource.java to remove all of > the "/certs" prefixes from the annotations instead of changing the > CertService.java implementations? > > > Or, based upon your pastebin: > > > uriInfo.getBaseUriBuilder() > .path(ShowsResource.class, "getShow") > .build(show.getId()); > > > @Path("shows") > public class ShowsResource { > > @GET > @Path("{showId}") > public String getShow ( > @PathParam("showId") long showId) { > return "HAHAHAHA"; > } > } > > > Generates: "context-root/45" Instead of > "context-root/shows/45" > are you are trying to introduce a new class (e. g. - > ShowsResource.java) which extends all of the other Resource classes so > that implementation Service classes such as CertService.java will call > ShowsResource.class instead of their CertResource.class directly? > > I presume that this interim class would provide an unchanging > interface to all of the underlying Resource classes (but perhaps its > annotations might need to change whenever an underlying Resource > changes)? > > To fix the immediate bug, could we simply check in my change to the > various branches and create a ticket for this work? > Presuming that the other two tickets ( PKI TRAC Ticket #728 - null > pointer exception thrown when processing 501 from dogtag 9-> 10 > instance and PKI TRAC Ticket #802 - Tomcat running as root) do not > need to be fixed at this time, this would allow us to proceed with > getting the Dogtag 10.0.7 builds finalized so that I can move on to > the more pressing Dogtag 10.1.1 issue. > > Thanks, > -- Matt > > I think you should be rather mapping to the relevant GET method instead > > using: > > > > http://docs.oracle.com/javaee/6/api/javax/ws/rs/core/UriBuilder.html#path%28java.lang.Class,%20java.lang.String%29 > > > > either: > > public abstract UriBuilder path(java.lang.Class resource, > > java.lang.String method) > > > > or: > > public abstract UriBuilder path(java.lang.reflect.Method method) > > > > In fact, we might want to open a ticket to confirm that all the rest of > > the URLs are likewise future-proofed against changes. > > > > Ade > > > > On Fri, 2014-03-07 at 18:48 -0800, Matthew Harmsen wrote: > > > Please review the following patch which addresses: > > > * PKI TRAC Ticket #868 - REST API get certs links missing > > > segment > > > > > > This patch has been tested on the DOGTAG_10_0_BRANCH as used on Fedora > > > 19: > > > > > > > > > Prior to the patch, the following URL: > > > > > > > > > * https://fedora19.example.com:8443/ca/rest/certs > > > > > > produces an XML page which contains XML such as: > > > > > > > > > * > > href="https://fedora19.example.com:8443/ca/rest/0x1" > > > rel="self"/> > > > > > > which produces an 'HTTP Status 404' page. > > > > > > > > > > > > After the patch has been applied, the same URL produces an XML > > > page which contains XML such as: > > > > > > > > > * > > href="https://fedora19.example.com:8443/ca/rest/certs/0x1" rel="self"/> > > > > > > which corresponds to a valid URL. > > > > > > > > > > > > NOTE: This patch needs to be applied to the DOGTAG_10_0_BRANCH > > > (Fedora 19), the DOGTAG_10_1_BRANCH (Fedora 20), and the master > > > (Fedora 21+). > > > This patch may also need to be applied to the > > > IPA_V3_RHEL_7_ERRATA_BRANCH. > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > From edewata at redhat.com Mon Mar 17 15:17:58 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Mar 2014 10:17:58 -0500 Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) In-Reply-To: <53234DA3.3040001@redhat.com> References: <531FC2DC.90404@redhat.com> <5321CBE4.7040806@redhat.com> <53234DA3.3040001@redhat.com> Message-ID: <53271226.70204@redhat.com> On 3/14/2014 1:42 PM, Christina Fu wrote: > Thank you Endi and Jack for your comments. > Attached please find the patch that addressed your comments. > > thanks, > Christina Just a few more comments: 1. The computeSessionKey() will throw an exception if it's missing the RESPONSE_STATUS. The other methods will just ignore that. I think they should be consistent. 2. Right now the code gets a string value from the response object, decodes the value into TPSBuffer, then puts it back to the same response object under the same name. Then the new Response classes would read from the same response object again. It works fine but code maintainer would have to be aware of the current type of the attribute because it could change. // response contains String or TPSBuffer values Hashtable response = parseResponse(content); value = (String) response.get(IRemoteRequest.TKS_RESPONSE_SessionKey); if (value == null) { CMS.debug(...); } else { CMS.debug(...); response.put(IRemoteRequest.TKS_RESPONSE_SessionKey, Util.specialDecode(value)); } return new TKSComputeSessionKeyResponse(response); It might be easier to simply wrap the original response object with the new Response class, then decode the value only when the attribute is used: // response contains string values Hashtable response = parseResponse(content); return new TKSComputeSessionKeyResponse(response); public TPSBuffer getSessionKey() { String value = response.get(IRemoteRequest.TKS_RESPONSE_SessionKey); if (value == null) return null; // decode value only when needed return Util.specialDecode(value)); } Or alternatively the new Response class can hold just the decoded values either in a separate hashtable or in fields: Hashtable response = parseResponse(content); TKSComputeSessionKeyResponse res = new TKSComputeSessionKeyResponse(); // don't use response value = response.get(IRemoteRequest.TKS_RESPONSE_SessionKey); if (value == null) { CMS.debug(...); } else { CMS.debug(...); // store decoded value res.setSessionKey(Util.specialDecode(value)); } return res; Issue #1 I think should be fixed. ACK once that is addressed. For #2, it's not a problem, but it would improve code clarity. I'll let you decide. Thanks. -- Endi S. Dewata From edewata at redhat.com Mon Mar 17 15:23:21 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Mar 2014 10:23:21 -0500 Subject: [Pki-devel] [PATCH] 421 Removed redundant GenericServlet.destroy() invocation. In-Reply-To: <531A945F.5040406@redhat.com> References: <531A945F.5040406@redhat.com> Message-ID: <53271369.2000606@redhat.com> On 3/7/2014 9:54 PM, Endi Sukma Dewata wrote: > The CMSStartServlet has been modified to remove the code that calls > GenericServlet.destroy() because it is an empty default implementation > which was intended to provide convenience for writing servlets. > > Ticket #896 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Mar 17 15:26:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Mar 2014 10:26:28 -0500 Subject: [Pki-devel] [PATCH] 423 Removed config path from web.xml. In-Reply-To: <531E7006.4070600@redhat.com> References: <531E7006.4070600@redhat.com> Message-ID: <53271424.6070006@redhat.com> On 3/10/2014 9:08 PM, Endi Sukma Dewata wrote: > Previously the CMSStartServlet always requires a cfgPath parameter > pointing to the CS.cfg location. By default the parameter points to > /conf//CS.cfg unless it's manually changed by > the admin after installation. > > Recently the servlet has been modified such that if the parameter > is not specified it will generate the default path automatically. > So it is no longer necessary to keep the cfgPath parameter in the > web.xml templates because it will point to the same location. > > This patch removes the cfgPath parameters from all web.xml templates. > This way newly created subsystems will not have this parameter, which > will help direct deployment in the future. An upgrade script has been > added to remove the parameter from existing instances if it points to > the default location. If the parameter points to a different location > that means the subsystem has been customized so it will not be changed. > > Ticket #748, #499 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Mar 17 15:28:00 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Mar 2014 10:28:00 -0500 Subject: [Pki-devel] [PATCH] 425 Added remove button handler for TPS UI. In-Reply-To: <5323209F.4000009@redhat.com> References: <5323209F.4000009@redhat.com> Message-ID: <53271480.4030904@redhat.com> On 3/14/2014 10:30 AM, Endi Sukma Dewata wrote: > The Table class has been modified to handle the remove button. > When the button is clicked, it will get the list of items selected > for deletion. If there is nothing selected it will not do anything. > If there are some items selected, it will display the list in a > dialog box and ask the user to confirm the deletion. If the operation > is confirmed, the items will be deleted one by one. The table will > be refreshed after the process is done. > > In some pages the buttons have been updated to reflect the > availability of the add/remove operations for the corresponding > REST resources. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Mar 17 15:52:04 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Mar 2014 10:52:04 -0500 Subject: [Pki-devel] [PATCH] 426 Added search filter for TPS resources. Message-ID: <53271A24.4040604@redhat.com> The TPS resources have been modified to accept a basic search filter for find operation. For resources based on LDAP database, the filtering is done using LDAP filter. For other resources, the filtering is done using string comparison. For now the filter is will only be matched against entry IDs. In the future the filter may be expanded to support other entry attributes. The CLI has been updated accordingly. The total attribute in DataCollection was changed from Integer into int because the total size of the collection cannot be null. The PKIException constructors have been consolidated into a single actual constructor. The other constructors have been modified to call the actual constructor with some default values. Ticket #847 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0426-Added-search-filter-for-TPS-resources.patch Type: text/x-patch Size: 58171 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 17 15:52:12 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Mar 2014 10:52:12 -0500 Subject: [Pki-devel] [PATCH] 427 Added search filter for TPS UI. Message-ID: <53271A2C.3010503@redhat.com> The tables in TPS UI has been modified to handle search filters. When the user presses enter in the search field, the UI will perform a search operation using the filter specified in the field. The table will be updated with the new results. If the filter is empty it will show all entries. Ticket #847 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0427-Added-search-filter-for-TPS-UI.patch Type: text/x-patch Size: 10088 bytes Desc: not available URL: From jmagne at redhat.com Tue Mar 18 02:18:14 2014 From: jmagne at redhat.com (John Magne) Date: Mon, 17 Mar 2014 22:18:14 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0005- Further work on TPS Processor, format operation.patch In-Reply-To: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> Message-ID: <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> Revised patch to address irc comments: Mostly concerning error handling and a new way to declare the TPSEngine class. ----- Original Message ----- > From: "John Magne" > To: "pki-devel" > Sent: Thursday, March 13, 2014 4:29:17 PM > Subject: [Pki-devel] [PATCH] 0004- Further work on TPS Processor, format operation.patch > > Ticket #895 https://fedorahosted.org/pki/ticket/895 > > Further work on TPS Processor, format operation. > > This patch gets a bit farther on the TPS format operation, just before applet > upgrade, which will also need secure channel functionality. > > Also, patch provides some misc clean up and functionality. > > 1. Method to calculate the token type. > 2. Some added convenience methods to get various config params for the Format > operation. > 3. More progress for the format operation up until we attempt to upgrade the > applet. > 4. Added TPSException that holds a message and end op return code. Can be > used to throw from anywhere and the return code makes it back to the client. > > > --- > > _______________________________________________ > 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: 0005-Further-work-on-TPS-Processor-format-operation.patch Type: text/x-patch Size: 17775 bytes Desc: not available URL: From mharmsen at redhat.com Tue Mar 18 03:31:12 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 17 Mar 2014 20:31:12 -0700 Subject: [Pki-devel] Seeking Karma for Dogtag 10.0.7 packages on Fedora 19 . . . Message-ID: <5327BE00.30106@redhat.com> Please provide Karma for the following six Dogtag 10.0.7 packages on Fedora 19: * dogtag-pki-10.0.7-1.fc19 * dogtag-pki-theme-10.0.7-1.fc19 * pki-core-10.0.7-1.fc19 * pki-console-10.0.7-1.fc19 * pki-ra-10.0.7-1.fc19 * pki-tps-10.0.7-1.fc19 This release resolves the following three PKI TRAC Tickets: * PKI TRAC Ticket #803 - avc generated for useradd in pkispawn scripts. * PKI TRAC Ticket #868 - REST API get certs links missing segment * PKI TRAC Ticket #869 - f19 ipa-server-install fails at step 6/22 of cert sys install - systemctl start pki-tomcatd.target fails Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Mar 18 15:38:46 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 18 Mar 2014 10:38:46 -0500 Subject: [Pki-devel] [PATCH] 428 Pagination improvement for TPS UI. Message-ID: <53286886.9020307@redhat.com> The TPS UI has been modified to provide buttons to go to the first page, previous page, next page, and last page. The UI will also show the total entries, the current page number, and the total number of pages. Users can jump to a specific page by entering the page number. The CSS has been modified to allow better control of UI components. The UI table now has a default size of 5. It's no longer necessary to specify the size in each table. Ticket #848 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0428-Pagination-improvement-for-TPS-UI.patch Type: text/x-patch Size: 34781 bytes Desc: not available URL: From edewata at redhat.com Tue Mar 18 17:10:01 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 18 Mar 2014 12:10:01 -0500 Subject: [Pki-devel] [PATCH] 0005- Further work on TPS Processor, format operation.patch In-Reply-To: <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> Message-ID: <53287DE9.8020905@redhat.com> On 3/17/2014 9:18 PM, John Magne wrote: > Revised patch to address irc comments: > > Mostly concerning error handling and a new way to declare the TPSEngine class. Some comments/questions: 1. Is the TPSFormatProcessor still needed since the TPSSession can use TPSProcessor directly? Or maybe should TPSProcessor.format() be moved into TPSFormatProcessor? 2. As discussed over IRC, the TPSProcessor.format() right now is using two mechanisms to return the status: via exception and via return value. Will it be changed to use one mechanism in the future? Also already discussed, the code that checks the return value of the check*() method can actually be moved into the check*() method itself, then throw an TPSException with the status if it fails the validation. 3. The cuid_x variable in getTokenType() doesn't seem to be necessary. It looks like it can use cuid directly. 4. In the following code, the getString() will assign a default value if the property is missing, so the exception will not happen for missing property. try { mappingOrder = configStore.getString(configName, null); } catch (EBaseException e1) { //The whole feature won't work if this is wrong. throw new TPSException( "TPSProcessor.getTokenType: Token Type configuration incorrect! Mising mapping order!", TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); } The exception could still happen for other errors, but in that case the exception message above will be incorrect. 5. The loop can be simplified like this: for (String mappingId : mappingOrder.split(",")) { ... } 6. Similar to #4, the following code will catch an incorrect type of error: try { targetTokenType = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { throw new TPSException( "TPSProcessor.getTokenType: Token Type configuration incorrect! Invalid or no targetTokenType.", TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); } 7. Similar to #4, the following code will assign a default value if the property is missing. If there's an exception, it must have been caused by something else, not because of the missing property. In that case it's better to break and report the error. try { tokenType = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { tokenType = null; } try { tokenATR = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { tokenATR = null; } try { tokenCUIDStart = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { tokenCUIDStart = null; } try { tokenCUIDEnd = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { targetTokenType = null; } try { majorVersion = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { majorVersion = null; } try { minorVersion = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { minorVersion = null; } The code should either wrap EBaseException with TPSException and throw it, or alternatively declare EBaseException in the getTokenType() and remove the try-catch block. 8. The following lines can be combined: int major = 0; major = Integer.parseInt(majorVersion); Same thing for the minor version. 9. There are checks in TPSProcessor to make sure the session is not null. This is no longer necessary since the session is supplied when creating the instance. If validation is necessary, it can be done just one time in the constructor itself: public TPSProcessor(TPSSession session) { if (session == null) throw NullPointerException("TPS session is null"); this.session = session; } -- Endi S. Dewata > ----- Original Message ----- >> From: "John Magne" >> To: "pki-devel" >> Sent: Thursday, March 13, 2014 4:29:17 PM >> Subject: [Pki-devel] [PATCH] 0004- Further work on TPS Processor, format operation.patch >> >> Ticket #895 https://fedorahosted.org/pki/ticket/895 >> >> Further work on TPS Processor, format operation. >> >> This patch gets a bit farther on the TPS format operation, just before applet >> upgrade, which will also need secure channel functionality. >> >> Also, patch provides some misc clean up and functionality. >> >> 1. Method to calculate the token type. >> 2. Some added convenience methods to get various config params for the Format >> operation. >> 3. More progress for the format operation up until we attempt to upgrade the >> applet. >> 4. Added TPSException that holds a message and end op return code. Can be >> used to throw from anywhere and the return code makes it back to the client. From akoneru at redhat.com Tue Mar 18 16:02:54 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 18 Mar 2014 12:02:54 -0400 Subject: [Pki-devel] [PATCH] 86-3 Addressed comments for patch 86-2 In-Reply-To: <459644204.9334947.1394646847761.JavaMail.zimbra@redhat.com> References: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> <1394130828.19497.1.camel@aleeredhat.laptop> <1394640687.23670.7.camel@akoneru.redhat.com> <459644204.9334947.1394646847761.JavaMail.zimbra@redhat.com> Message-ID: <1395158574.14594.2.camel@akoneru.redhat.com> Please review the patch 86-3 which addresses comments given for patch 86-2. Submitting both patches 86-2 and 86-3. Apply 86-3 on top of 86-2. Thanks, Abhishek On Wed, 2014-03-12 at 13:54 -0400, Abhishek Koneru wrote: > Please ignore the previous patch. Removed some unnecessary code. > > --Abhishek > > ----- Original Message ----- > From: "Abhishek Koneru" > To: alee at redhat.com > Cc: "pki-devel" > Sent: Wednesday, March 12, 2014 12:11:27 PM > Subject: Re: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side > > Please review the patch which addresses the comments below. > > CryptoOperationStore(): > > On the python side, we created an abstract class CryptoUtil to > > encapsulate the crypto operations we wanted to provide. The idea here > > was that the client might want to use some crypto library other than > > JSS. In the main program for the client then - in the python case, its > > drmtest.py, the client would elect to instantiate the relevant subclass > > of CryptoUtil. > > > > The way you have it now, the KeyClient is hardcoded to use NSS. This is > > not what we want. Instead do this: > > > > Create a new abstract class - CryptoProvider. This will contain methods > > that we will call in KeyClient. Note that the CryptoProvider cannot > > contain static methods. Then create a NSSCryptoUtil class that > > implements the required methods, does init() etc. > > > > DRMTest should instantiate and pass the NSSCryptoUtil class into the > > KeyClient constructor. > > > Created classes CryptoProvider and NSSCryptoProvider in > base/common/src/com/netscape/certsrv/util. An NSSCrypto provider object > is passed in PKIClient object that stores information about > configuration and connection. Since PKIClient is passed to KeyClient it > can access the CryptoProvider object from there. The reason for adding > CryptoProvider in PKIClient is that it can be used in future for all > kinds of crypto operations to be done in any client. > > KeyClient: > > 1. Extra S in param_id description in getKeyInfo() - instead of KeyId > > object - something more descriptive like - key id for secret. This > > applies in many cases. > > 2. Many comments do not specify what the return is. > > 3. In generateKey(), you do not use transWrappedSession key - you should > > at least pass that parameter if it is provided. > > 4. archiveKey() - typo in comment clinetKeyId > > There is a sentence fragment -- To be implemented ... ? > > 5. archiveKey() - there are Java classes to deal with OIDs - and in > > fact, this particular OID is defined within JSS. You should use those > > classes, rather than : > > String algorithmOID = "{1 2 840 113549 3 7}"; > > 6. > > > > KeyRequestResponse > > 1. Needs a XMLAccessType(None) > > Addressed all the comments except for 5. Did not find a way to get the > OID from the algorithm name in the JSS packages. Added it as a static > final variable in KeyRequestResource. > > > > I may have further comments when the patch is resubmitted. > > > > Ade > > > > On Tue, 2014-03-04 at 20:13 -0500, Abhishek Koneru wrote: > > > Please review the attached patch which replicates the new python client's KeyClient class > > > on the Java side. > > > > > > --Abhishek. > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > --Abhishek > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-86-2-Changes-to-KeyClient-on-the-java-side.patch Type: text/x-patch Size: 85568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-86-3-Address-comments-for-Patch-86-2.patch Type: text/x-patch Size: 45512 bytes Desc: not available URL: From cfu at redhat.com Tue Mar 18 18:02:33 2014 From: cfu at redhat.com (Christina Fu) Date: Tue, 18 Mar 2014 11:02:33 -0700 Subject: [Pki-devel] [PATCH] 0004- Further work on TPS Processor, format operation.patch In-Reply-To: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> Message-ID: <53288A39.2090202@redhat.com> I find it easier to just apply the patches to the tree to have a better context. Some of the things I've found may be from the past. * TPSEngine - - you have defined a number TKS_RESPONSE_xxx constants which I have defined in IRemoteRequest.java. I think IRemoteRequest.java is a better place since I have TKS server side using those constants as well. If agreed, how about removing those 6 constants from TPSEngine? I checked and i see in your code you are not using them yet anyway, so it should not be too much trouble. * TPSFormatProcessor - In our old tps, I have always questioned the existance of the RA_Format_Processor as well as the other xxx_Processor's other than the RA_Processor.cpp and RA_Enroll_Processor.cpp where the real code were in. My question is, is there going to be an attempt of putting real format code into the TPSFormatProcessor, etc, or we are merely going to do a direct conversion of C++ to Java? The reason why I ask is because the TPSFormatProcessor and all probably serve not much purpose unless we put something useful in them. We can probably leave them as is for now and think about it later. I just want to bring it up so we can keep it in mind to ponder on. * Would it make sense for APDUResponse to carry a boolean status so that checkTokenPDUResponse() only needs to be processed once and status set at the time? Anyway, if there is concern of veering off to far from the old tps course then we can keep the return rc style. * I don' t see in the format() where you pass in the skipAuth value. * I may have missed it, but I don't see you checking if cplc_data < 47 (a magic number in old tps). * why do you change the variable name token_status to status? I think token_status, or if you wish, tokenStatus, is more descriptive. * why do you check if (session == null) in the middle of assigning major and minor versions? Could you not have checked this earlier, like near the beginning of format()? * the old tps might be wrong, but I just want to know why is it that it would assign 0 to all those versions if token_status == NULL, while you bumped it out? * perhaps we want to consider keeping the tokenType somewhere we can retrieve (not re-calculated and re-retrieved) easily during a session, instead of passing it around as a parameter. Where is a good place to do that? that's it for now. Christina On 03/13/2014 04:29 PM, John Magne wrote: > Ticket #895 https://fedorahosted.org/pki/ticket/895 > > Further work on TPS Processor, format operation. > > This patch gets a bit farther on the TPS format operation, just before applet upgrade, which will also need secure channel functionality. > > Also, patch provides some misc clean up and functionality. > > 1. Method to calculate the token type. > 2. Some added convenience methods to get various config params for the Format operation. > 3. More progress for the format operation up until we attempt to upgrade the applet. > 4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client. > > > --- > > > _______________________________________________ > 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 cfu at redhat.com Tue Mar 18 18:02:40 2014 From: cfu at redhat.com (Christina Fu) Date: Tue, 18 Mar 2014 11:02:40 -0700 Subject: [Pki-devel] [PATCH] 0004- Further work on TPS Processor, format operation.patch In-Reply-To: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> Message-ID: <53288A40.7090403@redhat.com> I find it easier to just apply the patches to the tree to have a better context. Some of the things I've found may be from the past. * TPSEngine - - you have defined a number TKS_RESPONSE_xxx constants which I have defined in IRemoteRequest.java. I think IRemoteRequest.java is a better place since I have TKS server side using those constants as well. If agreed, how about removing those 6 constants from TPSEngine? I checked and i see in your code you are not using them yet anyway, so it should not be too much trouble. * TPSFormatProcessor - In our old tps, I have always questioned the existance of the RA_Format_Processor as well as the other xxx_Processor's other than the RA_Processor.cpp and RA_Enroll_Processor.cpp where the real code were in. My question is, is there going to be an attempt of putting real format code into the TPSFormatProcessor, etc, or we are merely going to do a direct conversion of C++ to Java? The reason why I ask is because the TPSFormatProcessor and all probably serve not much purpose unless we put something useful in them. We can probably leave them as is for now and think about it later. I just want to bring it up so we can keep it in mind to ponder on. * Would it make sense for APDUResponse to carry a boolean status so that checkTokenPDUResponse() only needs to be processed once and status set at the time? Anyway, if there is concern of veering off to far from the old tps course then we can keep the return rc style. * I don' t see in the format() where you pass in the skipAuth value. * I may have missed it, but I don't see you checking if cplc_data < 47 (a magic number in old tps). * why do you change the variable name token_status to status? I think token_status, or if you wish, tokenStatus, is more descriptive. * why do you check if (session == null) in the middle of assigning major and minor versions? Could you not have checked this earlier, like near the beginning of format()? * the old tps might be wrong, but I just want to know why is it that it would assign 0 to all those versions if token_status == NULL, while you bumped it out? * perhaps we want to consider keeping the tokenType somewhere we can retrieve (not re-calculated and re-retrieved) easily during a session, instead of passing it around as a parameter. Where is a good place to do that? that's it for now. Christina On 03/13/2014 04:29 PM, John Magne wrote: > Ticket #895 https://fedorahosted.org/pki/ticket/895 > > Further work on TPS Processor, format operation. > > This patch gets a bit farther on the TPS format operation, just before applet upgrade, which will also need secure channel functionality. > > Also, patch provides some misc clean up and functionality. > > 1. Method to calculate the token type. > 2. Some added convenience methods to get various config params for the Format operation. > 3. More progress for the format operation up until we attempt to upgrade the applet. > 4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client. > > > --- > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Mar 19 02:03:07 2014 From: jmagne at redhat.com (John Magne) Date: Tue, 18 Mar 2014 22:03:07 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch In-Reply-To: <53287DE9.8020905@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> <53287DE9.8020905@redhat.com> Message-ID: <1818607482.2838019.1395194587912.JavaMail.zimbra@redhat.com> Have addressed cfu's and edewatas comments in attached patch as per below: Prefix feature for some reason isn't working on the email. Comments encclosed in: comment Edewata's comments: Some comments/questions: 1. Is the TPSFormatProcessor still needed since the TPSSession can use TPSProcessor directly? Or maybe should TPSProcessor.format() be moved into TPSFormatProcessor? As per you and cfu, this one is history. We can always bring it back if we need to. The other processors to come will have significant content. 2. As discussed over IRC, the TPSProcessor.format() right now is using two mechanisms to return the status: via exception and via return value. Will it be changed to use one mechanism in the future? Also already discussed, the code that checks the return value of the check*() method can actually be moved into the check*() method itself, then throw an TPSException with the status if it fails the validation. Done, now we only return an exception. Also validations are inside check* methods when appropriate, based on intent of method. 3. The cuid_x variable in getTokenType() doesn't seem to be necessary. It looks like it can use cuid directly. Done 4. In the following code, the getString() will assign a default value if the property is missing, so the exception will not happen for missing property. try { mappingOrder = configStore.getString(configName, null); } catch (EBaseException e1) { //The whole feature won't work if this is wrong. throw new TPSException( "TPSProcessor.getTokenType: Token Type configuration incorrect! Mising mapping order!", TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); } Done. The exception could still happen for other errors, but in that case the exception message above will be incorrect. 5. The loop can be simplified like this: for (String mappingId : mappingOrder.split(",")) { ... } Done 6. Similar to #4, the following code will catch an incorrect type of error: try { targetTokenType = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { throw new TPSException( "TPSProcessor.getTokenType: Token Type configuration incorrect! Invalid or no targetTokenType.", TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); } Done 7. Similar to #4, the following code will assign a default value if the property is missing. If there's an exception, it must have been caused by something else, not because of the missing property. In that case it's better to break and report the error. try { tokenType = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { tokenType = null; } try { tokenATR = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { tokenATR = null; } try { tokenCUIDStart = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { tokenCUIDStart = null; } try { tokenCUIDEnd = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { targetTokenType = null; } try { majorVersion = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { majorVersion = null; } try { minorVersion = configStore.getString(mappingConfigName, null); } catch (EBaseException e) { minorVersion = null; } The code should either wrap EBaseException with TPSException and throw it, or alternatively declare EBaseException in the getTokenType() and remove the try-catch block. Done. Each exception in routine is handled based on whether we can tolerate a default. 8. The following lines can be combined: int major = 0; major = Integer.parseInt(majorVersion); Done Same thing for the minor version. 9. There are checks in TPSProcessor to make sure the session is not null. This is no longer necessary since the session is supplied when creating the instance. If validation is necessary, it can be done just one time in the constructor itself: public TPSProcessor(TPSSession session) { if (session == null) throw NullPointerException("TPS session is null"); this.session = session; } Done CFU's comments: I find it easier to just apply the patches to the tree to have a better context. Some of the things I've found may be from the past. * TPSEngine - - you have defined a number TKS_RESPONSE_xxx constants which I have defined in IRemoteRequest.java. I think IRemoteRequest.java is a better place since I have TKS server side using those constants as well. If agreed, how about removing those 6 constants from TPSEngine? I checked and i see in your code you are not using them yet anyway, so it should not be too much trouble. Done. * TPSFormatProcessor - In our old tps, I have always questioned the existance of the RA_Format_Processor as well as the other xxx_Processor's other than the RA_Processor.cpp and RA_Enroll_Processor.cpp where the real code were in. My question is, is there going to be an attempt of putting real format code into the TPSFormatProcessor, etc, or we are merely going to do a direct conversion of C++ to Java? The reason why I ask is because the TPSFormatProcessor and all probably serve not much purpose unless we put something useful in them. We can probably leave them as is for now and think about it later. I just want to bring it up so we can keep it in mind to ponder on. Done for both cfu and edewata. * Would it make sense for APDUResponse to carry a boolean status so that checkTokenPDUResponse() only needs to be processed once and status set at the time? Anyway, if there is concern of veering off to far from the old tps course then we can keep the return rc style. Done. Here I moved the method to get a boolean result into the APDUResponse class. Also added convenience class to get the two byte result for future use. * I don' t see in the format() where you pass in the skipAuth value. The original code didnt seem to be using this. If we determine otherwise, it can be fixed later. I suspect this is now controlled strictly by config. * I may have missed it, but I don't see you checking if cplc_data < 47 (a magic number in old tps). Done. I was checking this value in the subsequent methods that fish strings out of the cplc_data. Now have the check in cplc_data specific routine. * why do you change the variable name token_status to status? I think token_status, or if you wish, tokenStatus, is more descriptive. Done * why do you check if (session == null) in the middle of assigning major and minor versions? Could you not have checked this earlier, like near the beginning of format()? Done. Must have been some mystery fantom paste going on there. * the old tps might be wrong, but I just want to know why is it that it would assign 0 to all those versions if token_status == NULL, while you bumped it out? I believe this is the way it works. If there is no applet installed, there is no status. * perhaps we want to consider keeping the tokenType somewhere we can retrieve (not re-calculated and re-retrieved) easily during a session, instead of passing it around as a parameter. Where is a good place to do that? Good idea, done. that's it for now. Christina On 03/13/2014 04:29 PM, John Magne wrote: Ticket #895 https://fedorahosted.org/pki/ticket/895 Further work on TPS Processor, format operation. This patch gets a bit farther on the TPS format operation, just before applet upgrade, which will also need secure channel functionality. Also, patch provides some misc clean up and functionality. 1. Method to calculate the token type. 2. Some added convenience methods to get various config params for the Format operation. 3. More progress for the format operation up until we attempt to upgrade the applet. 4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Further-work-on-TPS-Processor-format-operation.patch Type: text/x-patch Size: 50011 bytes Desc: not available URL: From cfu at redhat.com Wed Mar 19 18:04:19 2014 From: cfu at redhat.com (Christina Fu) Date: Wed, 19 Mar 2014 11:04:19 -0700 Subject: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch In-Reply-To: <1818607482.2838019.1395194587912.JavaMail.zimbra@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> <53287DE9.8020905@redhat.com> <1818607482.2838019.1395194587912.JavaMail.zimbra@redhat.com> Message-ID: <5329DC23.10504@redhat.com> I checked areas addressing my comments. A couple things: * those logging/audit related log parameter name defines will eventually have to follow the other subsystems' param name style in CS.cfg (nothing to be done.) * I think at some point, we (both of us) have to define those exception messages in those properties file shared by other subsystems. Also, I'm not certain I like the introduction of TPSException. If EBaseException is not enough to serve your purpose, you should make it a more generic exception and put it at a place and make it available for all subsystems. (I'll leave it up to you, maybe consult Endi) * I might have missed it. I see you removed the session== null check but I don't see you putting it back near the top of format(). Consider it an ACK if you have addressed 3rd comment, and possible 2nd. Christina On 03/18/2014 07:03 PM, John Magne wrote: > Have addressed cfu's and edewatas comments in attached patch as per below: > > Prefix feature for some reason isn't working on the email. Comments encclosed in: comment > > Edewata's comments: > > > > > Some comments/questions: > > 1. Is the TPSFormatProcessor still needed since the TPSSession can use > TPSProcessor directly? Or maybe should TPSProcessor.format() be moved > into TPSFormatProcessor? > > > As per you and cfu, this one is history. We can always bring > it back if we need to. The other processors to come will have significant content. > > > > > 2. As discussed over IRC, the TPSProcessor.format() right now is using > two mechanisms to return the status: via exception and via return value. > Will it be changed to use one mechanism in the future? Also already > discussed, the code that checks the return value of the check*() method > can actually be moved into the check*() method itself, then throw an > TPSException with the status if it fails the validation. > > > Done, now we only return an exception. Also validations are > inside check* methods when appropriate, based on intent of method. > > > 3. The cuid_x variable in getTokenType() doesn't seem to be necessary. > It looks like it can use cuid directly. > > > Done > > > 4. In the following code, the getString() will assign a default value if > the property is missing, so the exception will not happen for missing > property. > > try { > mappingOrder = configStore.getString(configName, null); > } catch (EBaseException e1) { > //The whole feature won't work if this is wrong. > throw new TPSException( > "TPSProcessor.getTokenType: Token Type configuration > incorrect! Mising mapping order!", > TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); > } > > > Done. > > > > > > The exception could still happen for other errors, but in that case the > exception message above will be incorrect. > > 5. The loop can be simplified like this: > > for (String mappingId : mappingOrder.split(",")) { > ... > } > > > Done > > > > > 6. Similar to #4, the following code will catch an incorrect type of error: > > try { > targetTokenType = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > throw new TPSException( > "TPSProcessor.getTokenType: Token Type configuration > incorrect! Invalid or no targetTokenType.", > TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); > } > > > Done > > > > > > 7. Similar to #4, the following code will assign a default value if the > property is missing. If there's an exception, it must have been caused > by something else, not because of the missing property. In that case > it's better to break and report the error. > > try { > tokenType = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > tokenType = null; > } > > try { > tokenATR = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > tokenATR = null; > } > > try { > tokenCUIDStart = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > tokenCUIDStart = null; > } > > try { > tokenCUIDEnd = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > targetTokenType = null; > } > > try { > majorVersion = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > majorVersion = null; > } > > try { > minorVersion = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > minorVersion = null; > } > > The code should either wrap EBaseException with TPSException and throw > it, or alternatively declare EBaseException in the getTokenType() and > remove the try-catch block. > > > Done. Each exception in routine is handled based on whether we can > tolerate a default. > > > > > > > 8. The following lines can be combined: > > int major = 0; > major = Integer.parseInt(majorVersion); > > > Done > > > > > > Same thing for the minor version. > > > > 9. There are checks in TPSProcessor to make sure the session is not > null. This is no longer necessary since the session is supplied when > creating the instance. If validation is necessary, it can be done just > one time in the constructor itself: > > public TPSProcessor(TPSSession session) { > if (session == null) throw NullPointerException("TPS session is > null"); > this.session = session; > } > > > > Done > > > > > CFU's comments: > > I find it easier to just apply the patches to the tree to have a better context. Some of the things I've found may be from the past. > > * TPSEngine - > - you have defined a number TKS_RESPONSE_xxx constants which I have defined in IRemoteRequest.java. I think IRemoteRequest.java is a better place since I have TKS server side using those constants as well. If agreed, how about removing those 6 constants from TPSEngine? I checked and i see in your code you are not using them yet anyway, so it should not be too much trouble. > > > Done. > > > > > * TPSFormatProcessor > - In our old tps, I have always questioned the existance of the RA_Format_Processor as well as the other xxx_Processor's other than the RA_Processor.cpp and RA_Enroll_Processor.cpp where the real code were in. > My question is, is there going to be an attempt of putting real format code into the TPSFormatProcessor, etc, or we are merely going to do a direct conversion of C++ to Java? The reason why I ask is because the TPSFormatProcessor and all probably serve not much purpose unless we put something useful in them. We can probably leave them as is for now and think about it later. I just want to bring it up so we can keep it in mind to ponder on. > > > Done for both cfu and edewata. > > > * Would it make sense for APDUResponse to carry a boolean status so that checkTokenPDUResponse() only needs to be processed once and status set at the time? Anyway, if there is concern of veering off to far from the old tps course then we can keep the return rc style. > > > Done. Here I moved the method to get a boolean result into the APDUResponse class. Also added convenience class to get the two byte result for future use. > > > > * I don' t see in the format() where you pass in the skipAuth value. > > > The original code didnt seem to be using this. If we determine otherwise, it can be fixed later. > I suspect this is now controlled strictly by config. > > > > > > * I may have missed it, but I don't see you checking if cplc_data < 47 (a magic number in old tps). > > > Done. I was checking this value in the subsequent methods that fish strings out of the cplc_data. > Now have the check in cplc_data specific routine. > > > > > * why do you change the variable name token_status to status? I think token_status, or if you wish, tokenStatus, is more descriptive. > > > Done > > > * why do you check if (session == null) in the middle of assigning major and minor versions? Could you not have checked this earlier, like near the beginning of format()? > > Done. Must have been some mystery fantom paste going on there. > > * the old tps might be wrong, but I just want to know why is it that it would assign 0 to all those versions if token_status == NULL, while you bumped it out? > > I believe this is the way it works. If there is no applet installed, there is no status. > > > > * perhaps we want to consider keeping the tokenType somewhere we can retrieve (not re-calculated and re-retrieved) easily during a session, instead of passing it around as a parameter. Where is a good place to do that? > > > Good idea, done. > > > that's it for now. > Christina > > On 03/13/2014 04:29 PM, John Magne wrote: > > Ticket #895 https://fedorahosted.org/pki/ticket/895 > > Further work on TPS Processor, format operation. > > This patch gets a bit farther on the TPS format operation, just before applet upgrade, which will also need secure channel functionality. > > Also, patch provides some misc clean up and functionality. > > 1. Method to calculate the token type. > 2. Some added convenience methods to get various config params for the Format operation. > 3. More progress for the format operation up until we attempt to upgrade the applet. > 4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client. > > > > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Mar 19 19:03:03 2014 From: jmagne at redhat.com (John Magne) Date: Wed, 19 Mar 2014 15:03:03 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch In-Reply-To: <5329DC23.10504@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> <53287DE9.8020905@redhat.com> <1818607482.2838019.1395194587912.JavaMail.zimbra@redhat.com> <5329DC23.10504@redhat.com> Message-ID: <1200883470.3674734.1395255783743.JavaMail.zimbra@redhat.com> cfu, thanks for responses. My comments below: ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Wednesday, March 19, 2014 11:04:19 AM > Subject: Re: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch > > I checked areas addressing my comments. > > A couple things: > * those logging/audit related log parameter name defines will eventually have > to follow the other subsystems' param name style in CS.cfg (nothing to be > done.) > Yes, agreed. > * I think at some point, we (both of us) have to define those exception > messages in those properties file shared by other subsystems. > Also, I'm not certain I like the introduction of TPSException. If > EBaseException is not enough to serve your purpose, you should make it a > more generic exception and put it at a place and make it available for all > subsystems. cfu, TPSException is kind of specific to TPS since it carries a TPS specific error code that goes back to the client. It is true that EBaseException has a facility to add some generic object "parameters" of some kind, I though the new class might add some convenience and clarity. We can argue it going forward though. > (I'll leave it up to you, maybe consult Endi) > > * I might have missed it. I see you removed the session== null check but I > don't see you putting it back near the top of format(). cfu, On this one Endi had me to a null check on the session when creating the processor object constructor. > > Consider it an ACK if you have addressed 3rd comment, and possible 2nd. > > Christina > > > On 03/18/2014 07:03 PM, John Magne wrote: > > > > Have addressed cfu's and edewatas comments in attached patch as per below: > > Prefix feature for some reason isn't working on the email. Comments encclosed > in: comment > > Edewata's comments: > > > > > Some comments/questions: > > 1. Is the TPSFormatProcessor still needed since the TPSSession can use > TPSProcessor directly? Or maybe should TPSProcessor.format() be moved > into TPSFormatProcessor? > > > As per you and cfu, this one is history. We can always bring > it back if we need to. The other processors to come will have significant > content. > > > > > 2. As discussed over IRC, the TPSProcessor.format() right now is using > two mechanisms to return the status: via exception and via return value. > Will it be changed to use one mechanism in the future? Also already > discussed, the code that checks the return value of the check*() method > can actually be moved into the check*() method itself, then throw an > TPSException with the status if it fails the validation. > > > Done, now we only return an exception. Also validations are > inside check* methods when appropriate, based on intent of method. > > > 3. The cuid_x variable in getTokenType() doesn't seem to be necessary. > It looks like it can use cuid directly. > > > Done > > > 4. In the following code, the getString() will assign a default value if > the property is missing, so the exception will not happen for missing > property. > > try { > mappingOrder = configStore.getString(configName, null); > } catch (EBaseException e1) { > //The whole feature won't work if this is wrong. > throw new TPSException( > "TPSProcessor.getTokenType: Token Type configuration > incorrect! Mising mapping order!", > TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); > } > > > Done. > > > > > > The exception could still happen for other errors, but in that case the > exception message above will be incorrect. > > 5. The loop can be simplified like this: > > for (String mappingId : mappingOrder.split(",")) { > ... > } > > > Done > > > > > 6. Similar to #4, the following code will catch an incorrect type of error: > > try { > targetTokenType = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > throw new TPSException( > "TPSProcessor.getTokenType: Token Type configuration > incorrect! Invalid or no targetTokenType.", > TPSStatus.STATUS_ERROR_DEFAULT_TOKENTYPE_NOT_FOUND); > } > > > Done > > > > > > 7. Similar to #4, the following code will assign a default value if the > property is missing. If there's an exception, it must have been caused > by something else, not because of the missing property. In that case > it's better to break and report the error. > > try { > tokenType = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > tokenType = null; > } > > try { > tokenATR = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > tokenATR = null; > } > > try { > tokenCUIDStart = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > tokenCUIDStart = null; > } > > try { > tokenCUIDEnd = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > targetTokenType = null; > } > > try { > majorVersion = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > majorVersion = null; > } > > try { > minorVersion = configStore.getString(mappingConfigName, null); > } catch (EBaseException e) { > minorVersion = null; > } > > The code should either wrap EBaseException with TPSException and throw > it, or alternatively declare EBaseException in the getTokenType() and > remove the try-catch block. > > > Done. Each exception in routine is handled based on whether we can > tolerate a default. > > > > > > > 8. The following lines can be combined: > > int major = 0; > major = Integer.parseInt(majorVersion); > > > Done > > > > > > Same thing for the minor version. > > > > 9. There are checks in TPSProcessor to make sure the session is not > null. This is no longer necessary since the session is supplied when > creating the instance. If validation is necessary, it can be done just > one time in the constructor itself: > > public TPSProcessor(TPSSession session) { > if (session == null) throw NullPointerException("TPS session is > null"); > this.session = session; > } > > > > Done > > > > > CFU's comments: > > I find it easier to just apply the patches to the tree to have a better > context. Some of the things I've found may be from the past. > > * TPSEngine - > - you have defined a number TKS_RESPONSE_xxx constants which I have defined > in IRemoteRequest.java. I think IRemoteRequest.java is a better place > since I have TKS server side using those constants as well. If agreed, > how about removing those 6 constants from TPSEngine? I checked and i see > in your code you are not using them yet anyway, so it should not be too > much trouble. > > > Done. > > > > > * TPSFormatProcessor > - In our old tps, I have always questioned the existance of the > RA_Format_Processor as well as the other xxx_Processor's other than the > RA_Processor.cpp and RA_Enroll_Processor.cpp where the real code were in. > My question is, is there going to be an attempt of putting real format code > into the TPSFormatProcessor, etc, or we are merely going to do a direct > conversion of C++ to Java? The reason why I ask is because the > TPSFormatProcessor and all probably serve not much purpose unless we put > something useful in them. We can probably leave them as is for now and > think about it later. I just want to bring it up so we can keep it in > mind to ponder on. > > > Done for both cfu and edewata. > > > * Would it make sense for APDUResponse to carry a boolean status so that > checkTokenPDUResponse() only needs to be processed once and status set at > the time? Anyway, if there is concern of veering off to far from the old > tps course then we can keep the return rc style. > > > Done. Here I moved the method to get a boolean result into the APDUResponse > class. Also added convenience class to get the two byte result for future > use. > > > > * I don' t see in the format() where you pass in the skipAuth value. > > > The original code didnt seem to be using this. If we determine otherwise, it > can be fixed later. > I suspect this is now controlled strictly by config. > > > > > > * I may have missed it, but I don't see you checking if cplc_data < 47 (a > magic number in old tps). > > > Done. I was checking this value in the subsequent methods that fish strings > out of the cplc_data. > Now have the check in cplc_data specific routine. > > > > > * why do you change the variable name token_status to status? I think > token_status, or if you wish, tokenStatus, is more descriptive. > > > Done > > > * why do you check if (session == null) in the middle of assigning major and > minor versions? Could you not have checked this earlier, like near the > beginning of format()? > > Done. Must have been some mystery fantom paste going on there. > > * the old tps might be wrong, but I just want to know why is it that it would > assign 0 to all those versions if token_status == NULL, while you bumped it > out? > > I believe this is the way it works. If there is no applet installed, there > is no status. > > > > * perhaps we want to consider keeping the tokenType somewhere we can retrieve > (not re-calculated and re-retrieved) easily during a session, instead of > passing it around as a parameter. Where is a good place to do that? > > > Good idea, done. > > > that's it for now. > Christina > > On 03/13/2014 04:29 PM, John Magne wrote: > > Ticket #895 https://fedorahosted.org/pki/ticket/895 Further work on TPS > Processor, format operation. > > This patch gets a bit farther on the TPS format operation, just before > applet upgrade, which will also need secure channel functionality. > > Also, patch provides some misc clean up and functionality. > > 1. Method to calculate the token type. > 2. Some added convenience methods to get various config params for the > Format operation. > 3. More progress for the format operation up until we attempt to upgrade > the applet. > 4. Added TPSException that holds a message and end op return code. Can be > used to throw from anywhere and the return code makes it back to the > client. > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Mar 19 20:38:35 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 19 Mar 2014 15:38:35 -0500 Subject: [Pki-devel] [PATCH] 426 Added search filter for TPS resources. In-Reply-To: <53271A24.4040604@redhat.com> References: <53271A24.4040604@redhat.com> Message-ID: <532A004B.6000608@redhat.com> On 3/17/2014 10:52 AM, Endi Sukma Dewata wrote: > The TPS resources have been modified to accept a basic search filter > for find operation. For resources based on LDAP database, the filtering > is done using LDAP filter. For other resources, the filtering is done > using string comparison. For now the filter is will only be matched > against entry IDs. In the future the filter may be expanded to support > other entry attributes. The CLI has been updated accordingly. > > The total attribute in DataCollection was changed from Integer into int > because the total size of the collection cannot be null. > > The PKIException constructors have been consolidated into a single > actual constructor. The other constructors have been modified to > call the actual constructor with some default values. > > Ticket #847 Fixed a bug in the PKIException. ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Mar 19 21:12:15 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 19 Mar 2014 16:12:15 -0500 Subject: [Pki-devel] [PATCH] 429 Table refresh improvement for TPS UI. Message-ID: <532A082F.6050401@redhat.com> Currently when a table is refreshed the rows are deleted and recreated, which makes the UI appear slow. The process has been changed such that all rows are created initially, then when the refresh happens, it will simply overwrite the content of the rows and clear the unused ones. The Table class has been refactored such that operations such as add, remove, and open can be overriden by the subclass. It also has been modified to clear the checkboxes on refresh. The ID columns have been standardized to use "id" attribute name. The HTML templates have been modified to use a new CSS class for better control over formatting and to include a default page number. Ticet #848 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0429-Table-refresh-improvement-for-TPS-UI.patch Type: text/x-patch Size: 25331 bytes Desc: not available URL: From jmagne at redhat.com Thu Mar 20 01:01:56 2014 From: jmagne at redhat.com (John Magne) Date: Wed, 19 Mar 2014 21:01:56 -0400 (EDT) Subject: [Pki-devel] [PATCH] 428 Pagination improvement for TPS UI. In-Reply-To: <53286886.9020307@redhat.com> References: <53286886.9020307@redhat.com> Message-ID: <89138934.3901185.1395277316453.JavaMail.zimbra@redhat.com> ACK #427, and #428 Viewed demo with Endi, looked good. The filer feaure and pagination of results worked well. We suggested some future enhancments which will show up in a ticket near you. One particular nice to have would be a button to click in the search field. Now we rely upon hitting enter to initiate the search. ----- Original Message ----- From: "Endi Sukma Dewata" To: "pki-devel" Sent: Tuesday, March 18, 2014 8:38:46 AM Subject: [Pki-devel] [PATCH] 428 Pagination improvement for TPS UI. The TPS UI has been modified to provide buttons to go to the first page, previous page, next page, and last page. The UI will also show the total entries, the current page number, and the total number of pages. Users can jump to a specific page by entering the page number. The CSS has been modified to allow better control of UI components. The UI table now has a default size of 5. It's no longer necessary to specify the size in each table. Ticket #848 -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Mar 20 01:32:15 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 19 Mar 2014 20:32:15 -0500 Subject: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch In-Reply-To: <1200883470.3674734.1395255783743.JavaMail.zimbra@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> <53287DE9.8020905@redhat.com> <1818607482.2838019.1395194587912.JavaMail.zimbra@redhat.com> <5329DC23.10504@redhat.com> <1200883470.3674734.1395255783743.JavaMail.zimbra@redhat.com> Message-ID: <532A451F.8000400@redhat.com> Just one more comment, in TPSSession read(), write(), process(), and probably some methods in TPSProcessor, we can actually catch the IOException, log the message, then throw the original exception object. No need to create a new IOException wrapper because we aren't changing the exception type. try { ... } catch (IOException e) { CMS.debug(...); throw e; } Everything else is good, and the code is a lot easier to read. ACK. -- Endi S. Dewata From mharmsen at redhat.com Thu Mar 20 02:11:52 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 19 Mar 2014 19:11:52 -0700 Subject: [Pki-devel] [PATCH] TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca [20140319] Message-ID: <532A4E68.7070709@redhat.com> This patch causes the 'sslserver' certificate for a CA clone to be signed by its associated master CA during configuration, and resolves the following bug: * Dogtag TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca This was necessary to avoid any changes which may have been made to the X500Name directory string encoding order (i. e. - creating a Cloned CA on Fedora 20 from a Master CA on Fedora 19). This was also tested with an installation of IPA on Fedora 19, and a replica installation on Fedora 20 (after adding "|^/ca/ee/ca/profileSubmit" to the "/etc/httpd/conf.d/ipa-pki-proxy.conf" on the Fedora 19 master -- an IPA ticket will be filed for this issue). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20140319-Sign-CA-clone-sslserver-certificate-using-CA-master.patch Type: text/x-patch Size: 5645 bytes Desc: not available URL: From akoneru at redhat.com Thu Mar 20 13:42:04 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 20 Mar 2014 09:42:04 -0400 Subject: [Pki-devel] [PATCH] 86-3 Addressed comments for patch 86-2 In-Reply-To: <1395158574.14594.2.camel@akoneru.redhat.com> References: <285147700.7252294.1393982006040.JavaMail.zimbra@redhat.com> <1394130828.19497.1.camel@aleeredhat.laptop> <1394640687.23670.7.camel@akoneru.redhat.com> <459644204.9334947.1394646847761.JavaMail.zimbra@redhat.com> <1395158574.14594.2.camel@akoneru.redhat.com> Message-ID: <1395322924.3229.6.camel@akoneru.redhat.com> ACKe'd by Ade with some comments on IRC. Addressed the comments and pushed to master. --Abhishek On Tue, 2014-03-18 at 12:02 -0400, Abhishek Koneru wrote: > Please review the patch 86-3 which addresses comments given for patch > 86-2. Submitting both patches 86-2 and 86-3. Apply 86-3 on top of 86-2. > > Thanks, > Abhishek > On Wed, 2014-03-12 at 13:54 -0400, Abhishek Koneru wrote: > > Please ignore the previous patch. Removed some unnecessary code. > > > > --Abhishek > > > > ----- Original Message ----- > > From: "Abhishek Koneru" > > To: alee at redhat.com > > Cc: "pki-devel" > > Sent: Wednesday, March 12, 2014 12:11:27 PM > > Subject: Re: [Pki-devel] [PATCH] 86 Update KeyClient and DRMTest on the Java side similar to the python side > > > > Please review the patch which addresses the comments below. > > > CryptoOperationStore(): > > > On the python side, we created an abstract class CryptoUtil to > > > encapsulate the crypto operations we wanted to provide. The idea here > > > was that the client might want to use some crypto library other than > > > JSS. In the main program for the client then - in the python case, its > > > drmtest.py, the client would elect to instantiate the relevant subclass > > > of CryptoUtil. > > > > > > The way you have it now, the KeyClient is hardcoded to use NSS. This is > > > not what we want. Instead do this: > > > > > > Create a new abstract class - CryptoProvider. This will contain methods > > > that we will call in KeyClient. Note that the CryptoProvider cannot > > > contain static methods. Then create a NSSCryptoUtil class that > > > implements the required methods, does init() etc. > > > > > > DRMTest should instantiate and pass the NSSCryptoUtil class into the > > > KeyClient constructor. > > > > > Created classes CryptoProvider and NSSCryptoProvider in > > base/common/src/com/netscape/certsrv/util. An NSSCrypto provider object > > is passed in PKIClient object that stores information about > > configuration and connection. Since PKIClient is passed to KeyClient it > > can access the CryptoProvider object from there. The reason for adding > > CryptoProvider in PKIClient is that it can be used in future for all > > kinds of crypto operations to be done in any client. > > > KeyClient: > > > 1. Extra S in param_id description in getKeyInfo() - instead of KeyId > > > object - something more descriptive like - key id for secret. This > > > applies in many cases. > > > 2. Many comments do not specify what the return is. > > > 3. In generateKey(), you do not use transWrappedSession key - you should > > > at least pass that parameter if it is provided. > > > 4. archiveKey() - typo in comment clinetKeyId > > > There is a sentence fragment -- To be implemented ... ? > > > 5. archiveKey() - there are Java classes to deal with OIDs - and in > > > fact, this particular OID is defined within JSS. You should use those > > > classes, rather than : > > > String algorithmOID = "{1 2 840 113549 3 7}"; > > > 6. > > > > > > KeyRequestResponse > > > 1. Needs a XMLAccessType(None) > > > > Addressed all the comments except for 5. Did not find a way to get the > > OID from the algorithm name in the JSS packages. Added it as a static > > final variable in KeyRequestResource. > > > > > > I may have further comments when the patch is resubmitted. > > > > > > Ade > > > > > > On Tue, 2014-03-04 at 20:13 -0500, Abhishek Koneru wrote: > > > > Please review the attached patch which replicates the new python client's KeyClient class > > > > on the Java side. > > > > > > > > --Abhishek. > > > > _______________________________________________ > > > > Pki-devel mailing list > > > > Pki-devel at redhat.com > > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > > > > > > --Abhishek > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > From jmagne at redhat.com Thu Mar 20 18:25:19 2014 From: jmagne at redhat.com (John Magne) Date: Thu, 20 Mar 2014 14:25:19 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch In-Reply-To: <532A451F.8000400@redhat.com> References: <1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com> <1794126552.1614569.1395109094614.JavaMail.zimbra@redhat.com> <53287DE9.8020905@redhat.com> <1818607482.2838019.1395194587912.JavaMail.zimbra@redhat.com> <5329DC23.10504@redhat.com> <1200883470.3674734.1395255783743.JavaMail.zimbra@redhat.com> <532A451F.8000400@redhat.com> Message-ID: <223721792.5355966.1395339919159.JavaMail.zimbra@redhat.com> Ticket #895 Thanks to ACKs from edewata and cfu, pushed to master. ----- Original Message ----- > From: "Endi Sukma Dewata" > To: "John Magne" , "Christina Fu" > Cc: pki-devel at redhat.com > Sent: Wednesday, March 19, 2014 6:32:15 PM > Subject: Re: [Pki-devel] [PATCH] 0006- Further work on TPS Processor, format operation.patch > > Just one more comment, in TPSSession read(), write(), process(), and > probably some methods in TPSProcessor, we can actually catch the > IOException, log the message, then throw the original exception object. > No need to create a new IOException wrapper because we aren't changing > the exception type. > > try { > ... > } catch (IOException e) { > CMS.debug(...); > throw e; > } > > Everything else is good, and the code is a lot easier to read. ACK. > > -- > Endi S. Dewata > From akoneru at redhat.com Thu Mar 20 20:01:56 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 20 Mar 2014 16:01:56 -0400 (EDT) Subject: [Pki-devel] [PATCH] 87 Added new CLIs for Key resource In-Reply-To: <658839226.1719906.1395345711755.JavaMail.zimbra@redhat.com> Message-ID: <763729278.1719919.1395345716663.JavaMail.zimbra@redhat.com> Please review the patch which adds three new CLI commands key-show key-request-show key-mod --status [active/inactive] Thanks, Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0087-New-CLI-commands-for-Key-and-KeyRequest-resources.patch Type: text/x-patch Size: 9672 bytes Desc: not available URL: From cfu at redhat.com Thu Mar 20 20:42:25 2014 From: cfu at redhat.com (Christina Fu) Date: Thu, 20 Mar 2014 13:42:25 -0700 Subject: [Pki-devel] [PATCH] Ticket #888 - TPS rewrite: provide remote authority functions (patch 1: TKS functions) In-Reply-To: <53271226.70204@redhat.com> References: <531FC2DC.90404@redhat.com> <5321CBE4.7040806@redhat.com> <53234DA3.3040001@redhat.com> <53271226.70204@redhat.com> Message-ID: <532B52B1.6090207@redhat.com> Was told that there is a convention to follow -- reporting a push to the master when that happens... So here you go... pushed to master Christina On 03/17/2014 08:17 AM, Endi Sukma Dewata wrote: > On 3/14/2014 1:42 PM, Christina Fu wrote: >> Thank you Endi and Jack for your comments. >> Attached please find the patch that addressed your comments. >> >> thanks, >> Christina > > Just a few more comments: > > 1. The computeSessionKey() will throw an exception if it's missing the > RESPONSE_STATUS. The other methods will just ignore that. I think they > should be consistent. > > 2. Right now the code gets a string value from the response object, > decodes the value into TPSBuffer, then puts it back to the same > response object under the same name. Then the new Response classes > would read from the same response object again. It works fine but code > maintainer would have to be aware of the current type of the attribute > because it could change. > > // response contains String or TPSBuffer values > Hashtable response = parseResponse(content); > > value = (String) response.get(IRemoteRequest.TKS_RESPONSE_SessionKey); > if (value == null) { > CMS.debug(...); > } else { > CMS.debug(...); > response.put(IRemoteRequest.TKS_RESPONSE_SessionKey, > Util.specialDecode(value)); > } > > return new TKSComputeSessionKeyResponse(response); > > It might be easier to simply wrap the original response object with > the new Response class, then decode the value only when the attribute > is used: > > // response contains string values > Hashtable response = parseResponse(content); > return new TKSComputeSessionKeyResponse(response); > > public TPSBuffer getSessionKey() { > String value = > response.get(IRemoteRequest.TKS_RESPONSE_SessionKey); > if (value == null) return null; > // decode value only when needed > return Util.specialDecode(value)); > } > > Or alternatively the new Response class can hold just the decoded > values either in a separate hashtable or in fields: > > Hashtable response = parseResponse(content); > TKSComputeSessionKeyResponse res = > new TKSComputeSessionKeyResponse(); // don't use response > > value = response.get(IRemoteRequest.TKS_RESPONSE_SessionKey); > if (value == null) { > CMS.debug(...); > } else { > CMS.debug(...); > // store decoded value > res.setSessionKey(Util.specialDecode(value)); > } > > return res; > > Issue #1 I think should be fixed. ACK once that is addressed. > > For #2, it's not a problem, but it would improve code clarity. I'll > let you decide. Thanks. > From cfu at redhat.com Thu Mar 20 20:44:33 2014 From: cfu at redhat.com (Christina Fu) Date: Thu, 20 Mar 2014 13:44:33 -0700 Subject: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector service for JAVA-based TPS subsystem In-Reply-To: <5319232E.1090802@redhat.com> References: <53151ACC.1040309@redhat.com> <53166FD1.2090804@redhat.com> <5317BD5A.8050804@redhat.com> <5318B056.6070706@redhat.com> <5318DD14.9080403@redhat.com> <1531612659.29420154.1394155247092.JavaMail.zimbra@redhat.com> <5319232E.1090802@redhat.com> Message-ID: <532B5331.6070005@redhat.com> Was told that there is a convention to follow -- reporting a push to the master when that happens... So here you go... (well, from two weeks ago) pushed to master, Christina On 03/06/2014 05:38 PM, Christina Fu wrote: > Hi jack, > Thanks for the review! > Please see response below: > > On 03/06/2014 05:20 PM, John Magne wrote: >> ACK: >> >> I looked over the original and all the subsequent patches. >> Functionality looks good. Just a couple of quesitons. >> >> 1. Should we have some nice defines in the java code to use that >> represent the various known "ops". > Actually, these "ops" are admin-defined in the CS.cfg as explained in > the comments of ConnectionManager.java (about line 63 and on) . > I'd like to think of the callers being some kind of plugins that can > be written so I think it might be better not to hard-code them. > >> >> 2. How about some simple sample code somewhere in there that >> demonstrates the use of this feature. >> Maybe just make a call to the TKS to get random data, and show the >> code to handle the response? > > Very valid request. In fact, I have a patch coming soon (If I can be > allowed to check in this patch ;-) which will provide all the TKS > remote requests sending and response parsing. It is for ticket #888, > which I plan to submit in three batches, one for each remote > subsystem, starting with TKS. When it comes, not only will you be > able to see examples, you can just call these remote request handlers > and get response all sorted out and parsed for you. > >> >> ----- Original Message ----- >> From: "Endi Sukma Dewata" >> To: "Christina Fu" , pki-devel at redhat.com >> Sent: Thursday, March 6, 2014 12:39:48 PM >> Subject: Re: [Pki-devel] [PATCH] 862 TPS rewrite: provide connector >> service for JAVA-based TPS subsystem >> >> On 3/6/2014 11:28 AM, Christina Fu wrote: >>> I decided to change the default for connector enable's to false instead >>> of true so that the server can start even if no connectors are enabled. >>> >>> Attached please find the small patch. >>> >>> thanks, >>> Christina >> ACK. >> > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Sat Mar 22 00:38:11 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 21 Mar 2014 17:38:11 -0700 Subject: [Pki-devel] Seeking Karma for Dogtag 10.1.1 packages on Fedora 20 . . Message-ID: <532CDB73.1020409@redhat.com> Please provide Karma for the following six Dogtag 10.1.1 packages on Fedora 20: * dogtag-pki-theme-10.1.1-1.fc20 * pki-core-10.1.1-1.fc20 * pki-console-10.1.1-1.fc20 * pki-ra-10.1.1-1.fc20 * pki-tps-10.1.1-1.fc20 * dogtag-pki-10.1.1-1.fc20 This release resolves the following Bugzilla and four PKI TRAC Tickets: * Bugzilla Bug #1057959 - pkispawn requires policycoreutils-python * PKI TRAC Ticket #840 - pkispawn requires policycoreutils-python * PKI TRAC Ticket #868 - REST API get certs links missing segment * PKI TRAC Ticket #869 - f19 ipa-server-install fails at step 6/22 of cert sys install - systemctl start pki-tomcatd.target fails * PKI TRAC Ticket #816 - pki-tomcat cannot be started after installation of ipa replica with ca Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Mar 24 17:54:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Mar 2014 12:54:51 -0500 Subject: [Pki-devel] [PATCH] 430 Refactored UI framework. Message-ID: <5330716B.4030308@redhat.com> The current UI table assumes that the entries will be stored in a Collection object. Some tables might need different storage mechanisms, so the Table and TableItem classes have been refactored to allow sub- classes to override some of the operations. The Table initial render() method now will have to be called explicitly after object creation. The load() method in the Navigation class has been modified to pass the container element to the page being loaded. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0430-Refactored-UI-framework.patch Type: text/x-patch Size: 15681 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 24 17:55:30 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Mar 2014 12:55:30 -0500 Subject: [Pki-devel] [PATCH] 431 Added details page for TPS profiles. Message-ID: <53307192.8080309@redhat.com> A new page has been added to view TPS profile details. The properties aredisplayed in a table which provides pagination and search functionality. Currently the page is read-only. The edit functionality will be added separately later. Previously the ProfileData had a problem with JSON mapping because it incorrectly included a PropertyNames attribute. To fix the problem the class has been modified to require explicit JAXB mapping by setting the @XmlAccessorType to NONE. New CSS classes have been added to format the details page. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0431-Added-details-page-for-TPS-profiles.patch Type: text/x-patch Size: 12154 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 24 17:56:04 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Mar 2014 12:56:04 -0500 Subject: [Pki-devel] [PATCH] 432 Added details page for TPS connections. Message-ID: <533071B4.2020209@redhat.com> A new page has been added to view TPS connection details. The properties are displayed in a table which provides pagination and search functionality. Currently the page is read-only. The edit functionality will be added separately later. Previously the ConnectionData had a problem with JSON mapping because it incorrectly included a PropertyNames attribute. To fix the problem the class has been modified to require explicit JAXB mapping by setting the @XmlAccessorType to NONE. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0432-Added-details-page-for-TPS-connections.patch Type: text/x-patch Size: 8986 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 24 17:56:56 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Mar 2014 12:56:56 -0500 Subject: [Pki-devel] [PATCH] 433 Added details page for TPS authenticators. Message-ID: <533071E8.9070802@redhat.com> A new page has been added to view TPS authenticator details. The properties are displayed in a table which provides pagination and search functionality. Currently the page is read-only. The edit functionality will be added separately later. Previously the AuthenticatorData had a problem with JSON mapping because it incorrectly included a PropertyNames attribute. To fix the problem the class has been modified to require explicit JAXB mapping by setting the @XmlAccessorType to NONE. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0433-Added-details-page-for-TPS-authenticators.patch Type: text/x-patch Size: 9046 bytes Desc: not available URL: From cfu at redhat.com Mon Mar 24 19:10:17 2014 From: cfu at redhat.com (Christina Fu) Date: Mon, 24 Mar 2014 12:10:17 -0700 Subject: [Pki-devel] [PATCH] 862 HttpConnFactory addendum Message-ID: <53308319.8040501@redhat.com> The HttpConnFactory was apparently missed in #862 for multi-uri support. This patch adds such support. Please note that in order to add multi-uri support, the maximum connection is turned "soft" limit to accommodate the likely case that when the max has reached but no existing connection for a needed uri is present. To support this, the original Java Array is replaced by Vector instead for mConns so that the size can be flexible and increased to exceed the max when needed. The existing service for KRA was tested as well as the TPS (TKS, CA and mixed uri's) cases. Please review. thanks, Christina -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-trac-ticket-862-addendum-support-multi-uri-in-HttpCo.patch Type: text/x-patch Size: 10467 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 24 21:22:40 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Mar 2014 16:22:40 -0500 Subject: [Pki-devel] [PATCH] 862 HttpConnFactory addendum In-Reply-To: <53308319.8040501@redhat.com> References: <53308319.8040501@redhat.com> Message-ID: <5330A220.8090306@redhat.com> On 3/24/2014 2:10 PM, Christina Fu wrote: > The HttpConnFactory was apparently missed in #862 for multi-uri support. > This patch adds such support. Please note that in order to add > multi-uri support, the maximum connection is turned "soft" limit to > accommodate the likely case that when the max has reached but no > existing connection for a needed uri is present. > To support this, the original Java Array is replaced by Vector instead > for mConns so that the size can be flexible and increased to exceed the > max when needed. > The existing service for KRA was tested as well as the TPS (TKS, CA and > mixed uri's) cases. > > Please review. > > thanks, > Christina Some comments: 1. New codes should be written using Java collection framework (i.e. ArrayList) instead of Vector because it's lightweight, concise, more efficient, and easier to use with other collections. Vector is a legacy class and synchronized by default, but in most cases synchronization is not necessary or already handled by the class using the Vector. And if necessary, ArrayList can be synchronized as well so there's no need to use Vector unless for backward compatibility. Please see the following pages: http://javapostsforlearning.blogspot.com/2013/02/difference-between-arraylist-and-vector.html http://stackoverflow.com/questions/1386275/why-is-java-vector-class-considered-obsolete-or-deprecated 2. In HttpConnFactory.createConnection() it's not necessary to check whether retConn is null because the CMSEngine.getHttpConnection() will create a new instance which is never null. If it can't create a new instance it will throw an exception. 3. In HttpConnFactory.getConnForOp() there seems to be a possibility the mNumConns and mConns would no longer synced up. // the mNumConns is decreased here mNumConns--; for (int i = 0; i <= mNumConns; i++) { if (...) { mConns.removeElementAt(i); } else { // but here the mConns is not changed } } I'd suggest removing mNumConns and using mConns.size() instead. 4. In getConnForOp() if op is null it will remove an element but will still return a null: private IHttpConnection getConnForOp(String op) { IHttpConnection retConn = null; if (op == null) { retConn = mConns.elementAt(mNumConns); mConns.removeElementAt(mNumConns); } else { ... } return retConn; // return null? } Is this the correct behavior? Or should it return the removed element? To reduce possible similar errors I'd suggest in general to return from the method as soon as early as possible: private IHttpConnection getConnForOp(String op) { if (op == null) { retConn = mConns.elementAt(mNumConns); mConns.removeElementAt(mNumConns); return null; // return immediately } // otherwise continue with the method IHttpConnection retConn = null; ... } 5. In isConnForOp() and getConnForOp() the same element is being looked up multiple times: for (int i = 0; i <= mNumConns; i++) { if ((mConns.elementAt(i).getOp() != null) && op.equals(mConns.elementAt(i).getOp())) { ... } else { if (mConns.elementAt(i).getOp() != null) { ... It would be more efficient and easier to read to do the lookup once then reuse it: for (int i = 0; i <= mNumConns; i++) { String connOp = mConns.get(i).getOp(); if (connOp != null && op.equals(connOp)) { ... } else { if (connOp != null) { ... It's also possible to use for-each statement: for (IHttpConnection conn : mConns) { String connOp = conn.getOp(); if (connOp != null && op.equals(connOp)) { ... } else { if (connOp != null) { ... 6. The boolean literal comparison is not necessary: isConnForOp(op) == false It can be simplified as follows: !isConnForOp(op) The not (!) operator can only be used with boolean. It cannot be used to check null pointer, so there shouldn't be any ambiguity. 7. The following line: mConns.add(mNumConns++, boundconn); can be replaced with: mConns.add(boundconn); because List.add() will always add the element to the end of the list. 8. In HttpConnection the m-prefix and the null initialization is not necessary for the new attribute. Generally it's expected the attribute will have the same name as the setter/getter methods, and all attributes are null by default. protected String op; // null by default public String getOp() { return op; } public HttpConnection(..., String op) { this.op = op; } -- Endi S. Dewata From edewata at redhat.com Mon Mar 24 21:32:24 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 24 Mar 2014 16:32:24 -0500 Subject: [Pki-devel] [PATCH] 862 HttpConnFactory addendum In-Reply-To: <5330A220.8090306@redhat.com> References: <53308319.8040501@redhat.com> <5330A220.8090306@redhat.com> Message-ID: <5330A468.5020009@redhat.com> On 3/24/2014 4:22 PM, Endi Sukma Dewata wrote: > 4. In getConnForOp() if op is null it will remove an element but will > still return a null: > > private IHttpConnection getConnForOp(String op) { > IHttpConnection retConn = null; > if (op == null) { > retConn = mConns.elementAt(mNumConns); > mConns.removeElementAt(mNumConns); > } else { > ... > } > return retConn; // return null? > } > > Is this the correct behavior? Or should it return the removed element? Sorry, I misread the code. The method does return the removed element. In general it's still better to return from the method as early as possible: private IHttpConnection getConnForOp(String op) { ... if (op == null) { // return immediately return mConns.remove(mNumConns); } // otherwise continue with the method IHttpConnection retConn = null; ... } -- Endi S. Dewata From cfu at redhat.com Tue Mar 25 02:57:07 2014 From: cfu at redhat.com (Christina Fu) Date: Mon, 24 Mar 2014 19:57:07 -0700 Subject: [Pki-devel] [PATCH] 862 HttpConnFactory addendum In-Reply-To: <5330A468.5020009@redhat.com> References: <53308319.8040501@redhat.com> <5330A220.8090306@redhat.com> <5330A468.5020009@redhat.com> Message-ID: <5330F083.9090209@redhat.com> First of all, thanks to Jack (off-line) and Endi for the review. Attached is a replacement patch that supersedes the original patch. One main thing with this patch is that I took jack's suggestion and looked into possibility of adding uri after the HTTP Connection is created. This is different from the original ca->kra case where the uri is set at the time when HttpConneciton was created (originally, I was trying to preserve that). After looking carefully into it, I found it possible. Therefore, now we keep the connection unattached to any uri, op is no longer needed during the time when HttpConnection was created or retrieved. Before send, however, the uri will need to be set, and that's when op is used to retrieve the uri. I find this approach a lot cleaner. Although due to the change of the approach, many of Endi's comments do not immediately apply to this new patch, I was able to apply indirectly some of the concepts into the code in this patch. Please review. thanks, Christina On 03/24/2014 02:32 PM, Endi Sukma Dewata wrote: > On 3/24/2014 4:22 PM, Endi Sukma Dewata wrote: >> 4. In getConnForOp() if op is null it will remove an element but will >> still return a null: >> >> private IHttpConnection getConnForOp(String op) { >> IHttpConnection retConn = null; >> if (op == null) { >> retConn = mConns.elementAt(mNumConns); >> mConns.removeElementAt(mNumConns); >> } else { >> ... >> } >> return retConn; // return null? >> } >> >> Is this the correct behavior? Or should it return the removed element? > > Sorry, I misread the code. The method does return the removed element. > > In general it's still better to return from the method as early as > possible: > > private IHttpConnection getConnForOp(String op) { > ... > > if (op == null) { > // return immediately > return mConns.remove(mNumConns); > } > > // otherwise continue with the method > IHttpConnection retConn = null; > ... > } > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-trac-ticket-862-HTTP-connection-factory-multi-uri-ad.patch Type: text/x-patch Size: 14961 bytes Desc: not available URL: From anmajumd at cisco.com Tue Mar 25 16:31:54 2014 From: anmajumd at cisco.com (Anamitra Dutta Majumdar (anmajumd)) Date: Tue, 25 Mar 2014 16:31:54 +0000 Subject: [Pki-devel] Building guide for Dogtag 10.x In-Reply-To: <5330F083.9090209@redhat.com> Message-ID: I am looking for a build guide for building dog tag 10.x on a Fedora 19 platform. Is there any such document. Thanks, Anamitra From edewata at redhat.com Tue Mar 25 21:52:36 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Mar 2014 16:52:36 -0500 Subject: [Pki-devel] [PATCH] 434 Added buttons and dialogs to manage TPS properties. Message-ID: <5331FAA4.5000300@redhat.com> New buttons and dialogs have been added to add and remove properties in TPS profiles, connections, and authenticators. Currently the code will only change the properties in memory. The save functionality will be added separately later. Previously the Dialog class would only work with Models. The class has been refactored such that it will work with any storage mechanism. New CSS code was added to fix the dialog formatting. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0434-Added-buttons-and-dialogs-to-manage-TPS-properties.patch Type: text/x-patch Size: 21978 bytes Desc: not available URL: From cfu at redhat.com Wed Mar 26 15:06:51 2014 From: cfu at redhat.com (Christina Fu) Date: Wed, 26 Mar 2014 08:06:51 -0700 Subject: [Pki-devel] [PATCH] 862 HttpConnFactory addendum In-Reply-To: <5330F083.9090209@redhat.com> References: <53308319.8040501@redhat.com> <5330A220.8090306@redhat.com> <5330A468.5020009@redhat.com> <5330F083.9090209@redhat.com> Message-ID: <5332ED0B.9040701@redhat.com> pushed to master per acks from Jack and Endi. commit 35b8e2c69b86df07c2897e34861f4c6c636010a7 Christina From akoneru at redhat.com Thu Mar 27 13:37:22 2014 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 27 Mar 2014 09:37:22 -0400 Subject: [Pki-devel] [PATCH] 88 Refactoring KeyClient and NSSCryptoProvider classes Message-ID: <1395927442.4087.15.camel@akoneru.redhat.com> On discussing with Ade and Endi on IRC on the documentation for using the Java KeyClient, there were some comments that required refactoring the code a bit. Please review the patch which addresses the following comments: (for both code and documentation) Documentation link: http://pki.fedoraproject.org/wiki/Using_Java_Key_Client. 1. NSS setup - copy the p12 file to pki-user's $HOME and set the ownership to the user. -- Doc 2. Provide auxiliary methods archiveSymmetricKey and archivePassphrase -- Code 3. Remove try-catch blocks from code samples -- Doc 4. Replace "client server" with "application" -- Doc 5. The reference to DRMTest.java should point to the source in git repo. -- Doc 6. Improve description for Client Key Id -- Doc 7. Use a convenience method getKeyId() for KeyRequestResponse -- Doc and Code 8. Rename method archiveWrappedData to archiveEncryptedData -- Code. 9. Rename getWrappedData methods to getEncryptedData -- Code 10. Rename KeyClient.archiveOptionsData to archivePKIOptions -- Code 11. Replace "using" with "with" for all unwrap* and wrap* methods in CryptoProvider. -- Code 12. All base64 encode/decode should happen inside the client libraries. The user should not perform these operations. Add a new Key class which contains all the information in KeyData class but the base64 encoded attributes will already be decoded. All the retrieveKey* methods should return this object. -- Code 13. Rename archiving and retrieving data variables name to "secret" in cde snippets. -- Docs --Abhishek. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0088-Refactoring-KeyClient-class-and-crypto-classes.patch Type: text/x-patch Size: 51401 bytes Desc: not available URL: From alee at redhat.com Thu Mar 27 19:10:05 2014 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Mar 2014 15:10:05 -0400 Subject: [Pki-devel] [PATCH] 208 - Share subsystem cert for shared instances Message-ID: <1395947405.20582.2.camel@aleeredhat.laptop> Share subsytem cert in shared tomcat instances In shared tomcat instances, we need to share the subsystem cert and not create a new one for each additional subsystem added to the instance. In addtion, if the instances share the same database, then only one pkidebuser should be created with the relevant subsystem cert and seeAlso attribute. Ticket 893 Please review, Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0208-Share-subsytem-cert-in-shared-tomcat-instances.patch Type: text/x-patch Size: 18457 bytes Desc: not available URL: From alee at redhat.com Fri Mar 28 14:59:13 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 28 Mar 2014 10:59:13 -0400 Subject: [Pki-devel] Building guide for Dogtag 10.x In-Reply-To: References: Message-ID: <1396018753.2565.6.camel@aleeredhat.laptop> Hi, Sorry for the delayed response. I would have thought that we had something like that on the wiki, and all the information is there but its a little jumbled and confused. I'm going to put together a page that tells you how to go from a vanilla f20 machine to a working Dogtag 10 build. I'll announce it shortly. But in brief, the steps would be: 1. Get source code using git 2. Get dependencies using yum .. I will likely use the build requirements pki-core spec file in pki/specs as an initial guide. 3. Run pki/scripts/compose_pki_core_packages rpms Ade On Tue, 2014-03-25 at 16:31 +0000, Anamitra Dutta Majumdar (anmajumd) wrote: > I am looking for a build guide for building dog tag 10.x on a Fedora 19 > platform. Is there any such document. > > Thanks, > Anamitra > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Mar 28 16:22:27 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 28 Mar 2014 12:22:27 -0400 Subject: [Pki-devel] Building guide for Dogtag 10.x In-Reply-To: <1396018753.2565.6.camel@aleeredhat.laptop> References: <1396018753.2565.6.camel@aleeredhat.laptop> Message-ID: <1396023747.2565.13.camel@aleeredhat.laptop> We've added a new page on the wiki at: http://pki.fedoraproject.org/wiki/Building_Dogtag_10 Thanks, Ade On Fri, 2014-03-28 at 10:59 -0400, Ade Lee wrote: > Hi, > > Sorry for the delayed response. I would have thought that we had > something like that on the wiki, and all the information is there but > its a little jumbled and confused. > > I'm going to put together a page that tells you how to go from a vanilla > f20 machine to a working Dogtag 10 build. I'll announce it shortly. > > But in brief, the steps would be: > 1. Get source code using git > 2. Get dependencies using yum .. I will likely use the build > requirements pki-core spec file in pki/specs as an initial guide. > 3. Run pki/scripts/compose_pki_core_packages rpms > > Ade > > On Tue, 2014-03-25 at 16:31 +0000, Anamitra Dutta Majumdar (anmajumd) > wrote: > > I am looking for a build guide for building dog tag 10.x on a Fedora 19 > > platform. Is there any such document. > > > > Thanks, > > Anamitra > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From anmajumd at cisco.com Fri Mar 28 17:21:37 2014 From: anmajumd at cisco.com (Anamitra Dutta Majumdar (anmajumd)) Date: Fri, 28 Mar 2014 17:21:37 +0000 Subject: [Pki-devel] Building guide for Dogtag 10.x In-Reply-To: <1396023747.2565.13.camel@aleeredhat.laptop> Message-ID: Hi Ade, Thanks a lot for putting up this wiki.. -Anamitra On 3/28/14 9:22 AM, "Ade Lee" wrote: >We've added a new page on the wiki at: >http://pki.fedoraproject.org/wiki/Building_Dogtag_10 > >Thanks, >Ade > >On Fri, 2014-03-28 at 10:59 -0400, Ade Lee wrote: >> Hi, >> >> Sorry for the delayed response. I would have thought that we had >> something like that on the wiki, and all the information is there but >> its a little jumbled and confused. >> >> I'm going to put together a page that tells you how to go from a vanilla >> f20 machine to a working Dogtag 10 build. I'll announce it shortly. >> >> But in brief, the steps would be: >> 1. Get source code using git >> 2. Get dependencies using yum .. I will likely use the build >> requirements pki-core spec file in pki/specs as an initial guide. >> 3. Run pki/scripts/compose_pki_core_packages rpms >> >> Ade >> >> On Tue, 2014-03-25 at 16:31 +0000, Anamitra Dutta Majumdar (anmajumd) >> wrote: >> > I am looking for a build guide for building dog tag 10.x on a Fedora >>19 >> > platform. Is there any such document. >> > >> > Thanks, >> > Anamitra >> > >> > >> > _______________________________________________ >> > Pki-devel mailing list >> > Pki-devel at redhat.com >> > https://www.redhat.com/mailman/listinfo/pki-devel >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > From edewata at redhat.com Fri Mar 28 19:23:13 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 14:23:13 -0500 Subject: [Pki-devel] [PATCH] 434 Added buttons and dialogs to manage TPS properties. In-Reply-To: <5331FAA4.5000300@redhat.com> References: <5331FAA4.5000300@redhat.com> Message-ID: <5335CC21.6020106@redhat.com> On 3/25/2014 4:52 PM, Endi Sukma Dewata wrote: > New buttons and dialogs have been added to add and remove properties > in TPS profiles, connections, and authenticators. Currently the code > will only change the properties in memory. The save functionality > will be added separately later. > > Previously the Dialog class would only work with Models. The class > has been refactored such that it will work with any storage mechanism. > > New CSS code was added to fix the dialog formatting. > > Ticket #654 Some changes were missing. New patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0434-1-Added-buttons-and-dialogs-to-manage-TPS-properties.patch Type: text/x-patch Size: 23333 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 28 19:26:07 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 14:26:07 -0500 Subject: [Pki-devel] [PATCH] 435 Refactored TPS profiles. Message-ID: <5335CCCF.2000903@redhat.com> The TPS profile has been modified to use PATCH for update operation as required by Backbone. The ProfileData class has been modified to accept null properties to indicate that the properties are not being updated. The ProfileModel class has been modified to use JSON data type for enable and disable operations. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0435-Refactored-TPS-profiles.patch Type: text/x-patch Size: 11779 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 28 19:26:23 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 14:26:23 -0500 Subject: [Pki-devel] [PATCH] 436 Refactored TPS connections. Message-ID: <5335CCDF.6030209@redhat.com> The TPS connections has been modified to use PATCH for update operation as required by Backbone. The ConnectionData class has been modified to accept null properties to indicate that the properties are not being updated. The ConnectionModel class has been modified to use JSON data type for enable and disable operations. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0436-Refactored-TPS-connections.patch Type: text/x-patch Size: 11316 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 28 19:26:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 14:26:37 -0500 Subject: [Pki-devel] [PATCH] 437 Refactored TPS authenticators. Message-ID: <5335CCED.4090901@redhat.com> The TPS authenticators has been modified to use PATCH for update operation as required by Backbone. The AuthenticatorData class has been modified to accept null properties to indicate that the properties are not being updated. The AuthenticatorModel class has been modified to use JSON data type for enable and disable operations. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0437-Refactored-TPS-authenticators.patch Type: text/x-patch Size: 11559 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 28 19:26:51 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 14:26:51 -0500 Subject: [Pki-devel] [PATCH] 438 Added save functionality for some TPS resources. Message-ID: <5335CCFB.2070904@redhat.com> A new DetailsPage has been added to view and edit TPS resources including profiles, connections, and authenticators. Initially, in view mode the page is read-only. User can view properties but they are non-editable. To enter the edit mode the user needs to click the Edit link. In this mode the properties become editable. To save the all changes the user must click the Save button, and it will go back to view mode. The page also provides links to enable or disable the resource. The add functionality will be added separately later. New HTML templates and the CSS code have been modified to better control the formatting. Some unused code has been removed as well. Ticket #654 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0438-Added-save-functionality-for-some-TPS-resources.patch Type: text/x-patch Size: 46514 bytes Desc: not available URL: From alee at redhat.com Fri Mar 28 20:49:51 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 28 Mar 2014 16:49:51 -0400 Subject: [Pki-devel] [PATCH] 88 Refactoring KeyClient and NSSCryptoProvider classes In-Reply-To: <1395927442.4087.15.camel@akoneru.redhat.com> References: <1395927442.4087.15.camel@akoneru.redhat.com> Message-ID: <1396039791.5050.4.camel@aleeredhat.laptop> ACK. On Thu, 2014-03-27 at 09:37 -0400, Abhishek Koneru wrote: > On discussing with Ade and Endi on IRC on the documentation for using > the Java KeyClient, there were some comments that required refactoring > the code a bit. > > Please review the patch which addresses the following comments: (for > both code and documentation) > Documentation link: > http://pki.fedoraproject.org/wiki/Using_Java_Key_Client. > > 1. NSS setup - copy the p12 file to pki-user's $HOME and set the > ownership to the user. -- Doc > > 2. Provide auxiliary methods archiveSymmetricKey and archivePassphrase > -- Code > > 3. Remove try-catch blocks from code samples -- Doc > > 4. Replace "client server" with "application" -- Doc > > 5. The reference to DRMTest.java should point to the source in git repo. > -- Doc > > 6. Improve description for Client Key Id -- Doc > > 7. Use a convenience method getKeyId() for KeyRequestResponse -- Doc and > Code > > 8. Rename method archiveWrappedData to archiveEncryptedData -- Code. > > 9. Rename getWrappedData methods to getEncryptedData -- Code > > 10. Rename KeyClient.archiveOptionsData to archivePKIOptions -- Code > > 11. Replace "using" with "with" for all unwrap* and wrap* methods in > CryptoProvider. -- Code > > 12. All base64 encode/decode should happen inside the client libraries. > The user should not perform these operations. > Add a new Key class which contains all the information in KeyData class > but the base64 encoded attributes will already be decoded. All the > retrieveKey* methods should return this object. -- Code > > 13. Rename archiving and retrieving data variables name to "secret" in > cde snippets. -- Docs > > --Abhishek. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Mar 28 21:35:22 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 16:35:22 -0500 Subject: [Pki-devel] [PATCH] 428 Pagination improvement for TPS UI. In-Reply-To: <89138934.3901185.1395277316453.JavaMail.zimbra@redhat.com> References: <53286886.9020307@redhat.com> <89138934.3901185.1395277316453.JavaMail.zimbra@redhat.com> Message-ID: <5335EB1A.3040601@redhat.com> On 3/19/2014 8:01 PM, John Magne wrote: > ACK #427, and #428 Thanks. Pushed to master. > Viewed demo with Endi, looked good. The filer feaure and pagination of results worked well. > We suggested some future enhancments > which will show up in a ticket near you. > > One particular nice to have would be a button to click in the search field. > Now we rely upon hitting enter to initiate the search. I opened this ticket: https://fedorahosted.org/pki/ticket/921 -- Endi S. Dewata From edewata at redhat.com Fri Mar 28 21:37:22 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Mar 2014 16:37:22 -0500 Subject: [Pki-devel] [PATCH] 427 Added search filter for TPS UI. In-Reply-To: <53271A2C.3010503@redhat.com> References: <53271A2C.3010503@redhat.com> Message-ID: <5335EB92.7030000@redhat.com> On 3/17/2014 10:52 AM, Endi Sukma Dewata wrote: > The tables in TPS UI has been modified to handle search filters. When > the user presses enter in the search field, the UI will perform a search > operation using the filter specified in the field. The table will be > updated with the new results. If the filter is empty it will show all > entries. > > Ticket #847 ACKed by Jack in the other email. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:33:55 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:33:55 -0500 Subject: [Pki-devel] [PATCH] 429 Table refresh improvement for TPS UI. In-Reply-To: <532A082F.6050401@redhat.com> References: <532A082F.6050401@redhat.com> Message-ID: <53374A53.40109@redhat.com> On 3/19/2014 4:12 PM, Endi Sukma Dewata wrote: > Currently when a table is refreshed the rows are deleted and recreated, > which makes the UI appear slow. The process has been changed such that > all rows are created initially, then when the refresh happens, it will > simply overwrite the content of the rows and clear the unused ones. > > The Table class has been refactored such that operations such as add, > remove, and open can be overriden by the subclass. It also has been > modified to clear the checkboxes on refresh. The ID columns have been > standardized to use "id" attribute name. > > The HTML templates have been modified to use a new CSS class for better > control over formatting and to include a default page number. > > Ticet #848 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:34:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:34:25 -0500 Subject: [Pki-devel] [PATCH] 430 Refactored UI framework. In-Reply-To: <5330716B.4030308@redhat.com> References: <5330716B.4030308@redhat.com> Message-ID: <53374A71.7020208@redhat.com> On 3/24/2014 12:54 PM, Endi Sukma Dewata wrote: > The current UI table assumes that the entries will be stored in a > Collection object. Some tables might need different storage mechanisms, > so the Table and TableItem classes have been refactored to allow sub- > classes to override some of the operations. The Table initial render() > method now will have to be called explicitly after object creation. > > The load() method in the Navigation class has been modified to pass the > container element to the page being loaded. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:35:23 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:35:23 -0500 Subject: [Pki-devel] [PATCH] 431 Added details page for TPS profiles. In-Reply-To: <53307192.8080309@redhat.com> References: <53307192.8080309@redhat.com> Message-ID: <53374AAB.3020508@redhat.com> On 3/24/2014 12:55 PM, Endi Sukma Dewata wrote: > A new page has been added to view TPS profile details. The properties > aredisplayed in a table which provides pagination and search > functionality. Currently the page is read-only. The edit functionality > will be added separately later. > > Previously the ProfileData had a problem with JSON mapping because it > incorrectly included a PropertyNames attribute. To fix the problem the > class has been modified to require explicit JAXB mapping by setting the > @XmlAccessorType to NONE. > > New CSS classes have been added to format the details page. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:36:31 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:36:31 -0500 Subject: [Pki-devel] [PATCH] 432 Added details page for TPS connections. In-Reply-To: <533071B4.2020209@redhat.com> References: <533071B4.2020209@redhat.com> Message-ID: <53374AEF.5080809@redhat.com> On 3/24/2014 12:56 PM, Endi Sukma Dewata wrote: > A new page has been added to view TPS connection details. The properties > are displayed in a table which provides pagination and search > functionality. Currently the page is read-only. The edit functionality > will be added separately later. > > Previously the ConnectionData had a problem with JSON mapping because it > incorrectly included a PropertyNames attribute. To fix the problem the > class has been modified to require explicit JAXB mapping by setting the > @XmlAccessorType to NONE. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:37:02 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:37:02 -0500 Subject: [Pki-devel] [PATCH] 433 Added details page for TPS authenticators. In-Reply-To: <533071E8.9070802@redhat.com> References: <533071E8.9070802@redhat.com> Message-ID: <53374B0E.7090107@redhat.com> On 3/24/2014 12:56 PM, Endi Sukma Dewata wrote: > A new page has been added to view TPS authenticator details. The > properties are displayed in a table which provides pagination and search > functionality. Currently the page is read-only. The edit functionality > will be added separately later. > > Previously the AuthenticatorData had a problem with JSON mapping because > it incorrectly included a PropertyNames attribute. To fix the problem > the class has been modified to require explicit JAXB mapping by setting > the @XmlAccessorType to NONE. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:37:45 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:37:45 -0500 Subject: [Pki-devel] [PATCH] 434 Added buttons and dialogs to manage TPS properties. In-Reply-To: <5335CC21.6020106@redhat.com> References: <5331FAA4.5000300@redhat.com> <5335CC21.6020106@redhat.com> Message-ID: <53374B39.3060006@redhat.com> On 3/28/2014 2:23 PM, Endi Sukma Dewata wrote: > On 3/25/2014 4:52 PM, Endi Sukma Dewata wrote: >> New buttons and dialogs have been added to add and remove properties >> in TPS profiles, connections, and authenticators. Currently the code >> will only change the properties in memory. The save functionality >> will be added separately later. >> >> Previously the Dialog class would only work with Models. The class >> has been refactored such that it will work with any storage mechanism. >> >> New CSS code was added to fix the dialog formatting. >> >> Ticket #654 > > Some changes were missing. New patch attached. ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:38:16 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:38:16 -0500 Subject: [Pki-devel] [PATCH] 435 Refactored TPS profiles. In-Reply-To: <5335CCCF.2000903@redhat.com> References: <5335CCCF.2000903@redhat.com> Message-ID: <53374B58.2000309@redhat.com> On 3/28/2014 2:26 PM, Endi Sukma Dewata wrote: > The TPS profile has been modified to use PATCH for update operation as > required by Backbone. The ProfileData class has been modified to accept > null properties to indicate that the properties are not being updated. > The ProfileModel class has been modified to use JSON data type for > enable and disable operations. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:38:36 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:38:36 -0500 Subject: [Pki-devel] [PATCH] 436 Refactored TPS connections. In-Reply-To: <5335CCDF.6030209@redhat.com> References: <5335CCDF.6030209@redhat.com> Message-ID: <53374B6C.1030508@redhat.com> On 3/28/2014 2:26 PM, Endi Sukma Dewata wrote: > The TPS connections has been modified to use PATCH for update operation > as required by Backbone. The ConnectionData class has been modified to > accept null properties to indicate that the properties are not being > updated. The ConnectionModel class has been modified to use JSON data > type for enable and disable operations. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:39:09 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:39:09 -0500 Subject: [Pki-devel] [PATCH] 437 Refactored TPS authenticators. In-Reply-To: <5335CCED.4090901@redhat.com> References: <5335CCED.4090901@redhat.com> Message-ID: <53374B8D.4000705@redhat.com> On 3/28/2014 2:26 PM, Endi Sukma Dewata wrote: > The TPS authenticators has been modified to use PATCH for update > operation as required by Backbone. The AuthenticatorData class has > been modified to accept null properties to indicate that the > properties are not being updated. The AuthenticatorModel class has > been modified to use JSON data type for enable and disable > operations. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Mar 29 22:39:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Mar 2014 17:39:37 -0500 Subject: [Pki-devel] [PATCH] 438 Added save functionality for some TPS resources. In-Reply-To: <5335CCFB.2070904@redhat.com> References: <5335CCFB.2070904@redhat.com> Message-ID: <53374BA9.2010402@redhat.com> On 3/28/2014 2:26 PM, Endi Sukma Dewata wrote: > A new DetailsPage has been added to view and edit TPS resources > including profiles, connections, and authenticators. Initially, in > view mode the page is read-only. User can view properties but they > are non-editable. To enter the edit mode the user needs to click > the Edit link. In this mode the properties become editable. To save > the all changes the user must click the Save button, and it will go > back to view mode. The page also provides links to enable or disable > the resource. The add functionality will be added separately later. > > New HTML templates and the CSS code have been modified to better > control the formatting. Some unused code has been removed as well. > > Ticket #654 ACKed by Jack. Pushed to master. -- Endi S. Dewata From alee at redhat.com Mon Mar 31 14:31:59 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 31 Mar 2014 10:31:59 -0400 Subject: [Pki-devel] [PATCH] 208 - Share subsystem cert for shared instances In-Reply-To: <1395947405.20582.2.camel@aleeredhat.laptop> References: <1395947405.20582.2.camel@aleeredhat.laptop> Message-ID: <1396276319.9876.13.camel@aleeredhat.laptop> As per IRC, modified default.cfg to make the subsystem cert nick and subject dn subsystem agnostic and changed a couple of parameter names. Also determined that no further changes are required for the registerUser interface as it already checks for existing users. Acked by Endi and Christina. Pushed to master. On Thu, 2014-03-27 at 15:10 -0400, Ade Lee wrote: > Share subsytem cert in shared tomcat instances > > In shared tomcat instances, we need to share the subsystem cert and > not create a new one for each additional subsystem added to the instance. > In addtion, if the instances share the same database, then only one > pkidebuser should be created with the relevant subsystem cert and seeAlso > attribute. > > Ticket 893 > > Please review, > Thanks, > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel