From alee at redhat.com Fri Jun 1 13:41:05 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 01 Jun 2012 09:41:05 -0400 Subject: [Pki-devel] [PATCH] Fixes review comments on Patch Fixes for Coverity Issues in categories : CALL_SUPER, UNCONFIRMEDCAST, DEAD_STORE, TOSTRING_ARRAY In-Reply-To: <1338404970.1790.2.camel@abhishek> References: <1337970446.25022.3.camel@abhishek> <1338306264.3069.10.camel@aleeredhat.laptop> <1338404970.1790.2.camel@abhishek> Message-ID: <1338558066.3069.42.camel@aleeredhat.laptop> Pushed to master (patches 7 and 8) Ade On Wed, 2012-05-30 at 15:09 -0400, Abhishek Koneru wrote: > Please find attached the patch which contains fixes for review comments > given. > Smoke Test Passes. > > Regards, > Abhishek Koneru > > On Tue, 2012-05-29 at 11:44 -0400, Ade Lee wrote: > > Comments: > > > > 1. The fix in Resender.java is not correct - that is > > replyRequestId.toString() is not the same as > > replymsg.reqId.substring(index + 1). There are some conversions that > > take place. > > > > I'm OK with reverting your fix here, and marking the bug as > > intentional/ignore. > > > > 2. In SelfTestSubsystem.java, remove the comments as well: > > // strip preceding/trailing whitespace > > // from passed-in String parameters > > > > 3. In CMCRevoke, no need to specify : String asciiBASE64Blob = null; > > You can just specify String asciiBASE64Blob; > > > > 4. In Request.java, you can specify StringBuffer s = con.getPage(); > > > > 5. In PKCS7.java, you need the new byte[] data = byte[len] in case > > dis.available() == 0 . I'm not sure I like the way this method is > > written. Lets revert the fix and leave this unfixed for now. > > > > 6. Can you explain to me why you think adding the Override tags will fix > > the call_super issues? > > > > Ade > > > > > > On Fri, 2012-05-25 at 14:27 -0400, Abhishek Koneru wrote: > > > Please find attached the patch with fixes for some of the coverity > > > issues for review. > > > > > > Thanks & Regards, > > > Abhishek > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Jun 1 17:20:28 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 01 Jun 2012 12:20:28 -0500 Subject: [Pki-devel] [PATCH] Fixes for Some of the Coverity Issues under NULL_RETURNS category for Dog Tag 10 for Review In-Reply-To: <1338503155.8316.7.camel@abhishek> References: <1338503155.8316.7.camel@abhishek> Message-ID: <4FC8F9DC.2040803@redhat.com> On 5/31/2012 5:25 PM, Abhishek Koneru wrote: > Please find attached the patch with fixes for some 40-50 defects of type > NULL_RETURNS in Coverity for Dog Tag 10. > Please review the patch > The build passed Smoke Test. Generally in Java a method should throw an exception if it encounters an error so the caller can know what the problem is and can handle it properly. A method should return null only if it couldn't find the object it's looking for. Some of the current code are doing this in C-style, returning null on error, so the caller will have to explicitly handle it. Fixing this behavior will require a major change, so for now we'd have to stick with the current behavior, but we should have a discussion about this. 1. In CAService.java:1503 the serialNoArray could be null if the serial number is not found or invalid. The exception message should say that too. To be consistent it should throw ECAException with user message CMS_CA_MISSING_SERIAL_NUMBER. Ideally the getExtDataInBigIntegerArray() should throw an exception on invalid data. 2. In CRLIssuingPoint.java:1929,1949 the original code would throw an exception if the return value is null. The new code logs the error but continues processing the next request. I think they should throw an exception like in #1. Or, if the error is supposed to be ignored, please add a comment there. Ideally the getExtDataInRevokedCertArray() should throw an exception on invalid data. 3. In CRLIssuingPoint.java:1949-1957 the code needs to be formatted properly. You can use Eclipse to auto format that section. 4. In StatsEvent.java:37 the mSubEvents should have been a Map instead of a Vector so we can look up by name easily. Please open a ticket for this, or feel free to include it in the next patch. 5. In CrossCertPairSubsystem.java:191,405 the code will throw an exception if getConn() returns null. Instead of checking for the return value in all invocations, it would be better to do it inside getConn() itself. Ideally the LdapBoundConnFactory.getConn() should throw an exception if it cannot create a connection. 6. In HttpPKIMessage.java:77 instead of checking for null return value it might be better to change the RequestTransfer .getTransferAttributes() to always return an array (which could be empty but not null) like this: return v.toArray(new String[v.size()]); This way the change in RequestTransfer.java:110 is no longer needed. 7. There's a typo in DBRegistry.java:460. To be consistent it should throw EDBException. The message should be added into base/common/src/UserMessages.properties, something like this: CMS_DBS_MISSING_OBJECT_CLASS=Missing object class While you're at it.. :) the code in 472-481 could be simplified into: String[] s = attr.getStringValueArray(); Feel free to include it in your next patch or just file a ticket. 8. The LdapPredicateParser.nextToken() should never return null, so instead of checking the return value you can throw the exception in line 330. Same thing with PolicyPredicateParser.java:331. 9. In PublisherProcessor.java:495,539 instead of checking for null getType(), the comparison can be changed like this: publishingType.equals(rule.getType()) Also the loop itself can be simplified as follows: Enumeration e = mRuleInsts.elements(); while (e.hasMoreElements()) { LdapRule rule = (LdapRule)e.nextElement(); ... } This way we don't need to worry about null name (which shouldn't happen anyway) so getRules() won't need to return null. 10. In LogSubsystem.java:206 the code was changed from catching EBaseException to catching all Exception. Any reason for that? This might be too broad, we should let real errors (e.g. RuntimeException) be handled by the caller. You can leave the e.printStackTrace() there if you want. 11. In CertificateInfo.java:197 if sigAlgId == null and algm == null it will not create new AlgorithmId so the sigAlgId will remain null, which is not what we want. The original code would have thrown an Exception. I think you should check the KeyCertUtil.getSigningAlgorithm() in line 191, if it returns null you should throw NoSuchAlgorithmException. 12. Similar to #5, in UGSubsystem.java instead of checking each getConn() invocation you can check it inside getConn() itself and throw the exception there. 13. In EnrollmentService.java:738,791 you should use user message CMS_BASE_CERT_NOT_FOUND. The message itself in UserMessages.properties should be changed to: Certificate not found or invalid Similarly, ideally the getExtDataInCertInfoArray() should throw an exception on invalid data. 14. In HttpMessage.java:120 the readLine() will return null if it reaches EOF. There's already a code there to detect this, but I'm not sure why it was commented out. I think we should uncomment it. 15. In PrettyPrintFormat.toHexString() the original code would throw an exception if the input byte array is empty. In the new code it will return a string that contain indentations only (line 122). Also there's still a possibility of an exception in line 115 if in == null and lineLen == 0. It might be better to just check the array at the beginning of the method and throw an exception. Or don't change anything, it will throw an exception too. Was this problem reported by Coverity as NULL_RETURNS? I don't see any method returning null value here. 16. In KeyUsageExtension.java:213 the original constructor will fail if it couldn't get the bitString from the value. Now it will construct the KeyUsageExtension with null bitString. It might be better to check the return value of getUnalignedBitString() and throw IOException("Invalid bit string") or something like that. -- Endi S. Dewata From akoneru at redhat.com Mon Jun 4 18:43:19 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 04 Jun 2012 14:43:19 -0400 Subject: [Pki-devel] [PATCH] for Re: [PATCH] Fixes for Some of the Coverity Issues under NULL_RETURNS category for Dog Tag 10 for Review In-Reply-To: <4FC8F9DC.2040803@redhat.com> References: <1338503155.8316.7.camel@abhishek> <4FC8F9DC.2040803@redhat.com> Message-ID: <1338835399.16140.3.camel@abhishek> Please find attached the fixes addressing all the review comments. The build passed the smoke test. Regards, Abhishek Koneru On Fri, 2012-06-01 at 12:20 -0500, Endi Sukma Dewata wrote: > On 5/31/2012 5:25 PM, Abhishek Koneru wrote: > > Please find attached the patch with fixes for some 40-50 defects of type > > NULL_RETURNS in Coverity for Dog Tag 10. > > Please review the patch > > The build passed Smoke Test. > > Generally in Java a method should throw an exception if it encounters an > error so the caller can know what the problem is and can handle it > properly. A method should return null only if it couldn't find the > object it's looking for. Some of the current code are doing this in > C-style, returning null on error, so the caller will have to explicitly > handle it. Fixing this behavior will require a major change, so for now > we'd have to stick with the current behavior, but we should have a > discussion about this. > > 1. In CAService.java:1503 the serialNoArray could be null if the serial > number is not found or invalid. The exception message should say that > too. To be consistent it should throw ECAException with user message > CMS_CA_MISSING_SERIAL_NUMBER. > > Ideally the getExtDataInBigIntegerArray() should throw an exception on > invalid data. > > 2. In CRLIssuingPoint.java:1929,1949 the original code would throw an > exception if the return value is null. The new code logs the error but > continues processing the next request. I think they should throw an > exception like in #1. Or, if the error is supposed to be ignored, please > add a comment there. > > Ideally the getExtDataInRevokedCertArray() should throw an exception on > invalid data. > > 3. In CRLIssuingPoint.java:1949-1957 the code needs to be formatted > properly. You can use Eclipse to auto format that section. > > 4. In StatsEvent.java:37 the mSubEvents should have been a Map instead > of a Vector so we can look up by name easily. Please open a ticket for > this, or feel free to include it in the next patch. > > 5. In CrossCertPairSubsystem.java:191,405 the code will throw an > exception if getConn() returns null. Instead of checking for the return > value in all invocations, it would be better to do it inside getConn() > itself. > > Ideally the LdapBoundConnFactory.getConn() should throw an exception if > it cannot create a connection. > > 6. In HttpPKIMessage.java:77 instead of checking for null return value > it might be better to change the RequestTransfer > .getTransferAttributes() to always return an array (which could be empty > but not null) like this: > > return v.toArray(new String[v.size()]); > > This way the change in RequestTransfer.java:110 is no longer needed. > > 7. There's a typo in DBRegistry.java:460. To be consistent it should > throw EDBException. The message should be added into > base/common/src/UserMessages.properties, something like this: > > CMS_DBS_MISSING_OBJECT_CLASS=Missing object class > > While you're at it.. :) the code in 472-481 could be simplified into: > > String[] s = attr.getStringValueArray(); > > Feel free to include it in your next patch or just file a ticket. > > 8. The LdapPredicateParser.nextToken() should never return null, so > instead of checking the return value you can throw the exception in line > 330. > > Same thing with PolicyPredicateParser.java:331. > > 9. In PublisherProcessor.java:495,539 instead of checking for null > getType(), the comparison can be changed like this: > > publishingType.equals(rule.getType()) > > Also the loop itself can be simplified as follows: > > Enumeration e = mRuleInsts.elements(); > while (e.hasMoreElements()) { > LdapRule rule = (LdapRule)e.nextElement(); > ... > } > > This way we don't need to worry about null name (which shouldn't happen > anyway) so getRules() won't need to return null. > > 10. In LogSubsystem.java:206 the code was changed from catching > EBaseException to catching all Exception. Any reason for that? This > might be too broad, we should let real errors (e.g. RuntimeException) be > handled by the caller. You can leave the e.printStackTrace() there if > you want. > > 11. In CertificateInfo.java:197 if sigAlgId == null and algm == null it > will not create new AlgorithmId so the sigAlgId will remain null, which > is not what we want. The original code would have thrown an Exception. I > think you should check the KeyCertUtil.getSigningAlgorithm() in line > 191, if it returns null you should throw NoSuchAlgorithmException. > > 12. Similar to #5, in UGSubsystem.java instead of checking each > getConn() invocation you can check it inside getConn() itself and throw > the exception there. > > 13. In EnrollmentService.java:738,791 you should use user message > CMS_BASE_CERT_NOT_FOUND. The message itself in UserMessages.properties > should be changed to: > > Certificate not found or invalid > > Similarly, ideally the getExtDataInCertInfoArray() should throw an > exception on invalid data. > > 14. In HttpMessage.java:120 the readLine() will return null if it > reaches EOF. There's already a code there to detect this, but I'm not > sure why it was commented out. I think we should uncomment it. > > 15. In PrettyPrintFormat.toHexString() the original code would throw an > exception if the input byte array is empty. In the new code it will > return a string that contain indentations only (line 122). Also there's > still a possibility of an exception in line 115 if in == null and > lineLen == 0. > > It might be better to just check the array at the beginning of the > method and throw an exception. Or don't change anything, it will throw > an exception too. Was this problem reported by Coverity as NULL_RETURNS? > I don't see any method returning null value here. > > 16. In KeyUsageExtension.java:213 the original constructor will fail if > it couldn't get the bitString from the value. Now it will construct the > KeyUsageExtension with null bitString. It might be better to check the > return value of getUnalignedBitString() and throw IOException("Invalid > bit string") or something like that. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0010-Fixes-for-review-comments-for-NULL_RETURNS-Coverity-.patch Type: text/x-patch Size: 45270 bytes Desc: not available URL: From akoneru at redhat.com Mon Jun 4 20:10:46 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 04 Jun 2012 16:10:46 -0400 Subject: [Pki-devel] [PATCH]10-2 Fixes for Some of the Coverity Issues under NULL_RETURNS category for Dog Tag 10 for review and commit In-Reply-To: <1338835399.16140.3.camel@abhishek> References: <1338503155.8316.7.camel@abhishek> <4FC8F9DC.2040803@redhat.com> <1338835399.16140.3.camel@abhishek> Message-ID: <1338840646.16140.7.camel@abhishek> Please find attached the patch with fixes for issues in the previous patch[#10] for review. --Abhishek Koneru On Mon, 2012-06-04 at 14:43 -0400, Abhishek Koneru wrote: > Please find attached the fixes addressing all the review comments. > The build passed the smoke test. > > Regards, > Abhishek Koneru > > On Fri, 2012-06-01 at 12:20 -0500, Endi Sukma Dewata wrote: > > On 5/31/2012 5:25 PM, Abhishek Koneru wrote: > > > Please find attached the patch with fixes for some 40-50 defects of type > > > NULL_RETURNS in Coverity for Dog Tag 10. > > > Please review the patch > > > The build passed Smoke Test. > > > > Generally in Java a method should throw an exception if it encounters an > > error so the caller can know what the problem is and can handle it > > properly. A method should return null only if it couldn't find the > > object it's looking for. Some of the current code are doing this in > > C-style, returning null on error, so the caller will have to explicitly > > handle it. Fixing this behavior will require a major change, so for now > > we'd have to stick with the current behavior, but we should have a > > discussion about this. > > > > 1. In CAService.java:1503 the serialNoArray could be null if the serial > > number is not found or invalid. The exception message should say that > > too. To be consistent it should throw ECAException with user message > > CMS_CA_MISSING_SERIAL_NUMBER. > > > > Ideally the getExtDataInBigIntegerArray() should throw an exception on > > invalid data. > > > > 2. In CRLIssuingPoint.java:1929,1949 the original code would throw an > > exception if the return value is null. The new code logs the error but > > continues processing the next request. I think they should throw an > > exception like in #1. Or, if the error is supposed to be ignored, please > > add a comment there. > > > > Ideally the getExtDataInRevokedCertArray() should throw an exception on > > invalid data. > > > > 3. In CRLIssuingPoint.java:1949-1957 the code needs to be formatted > > properly. You can use Eclipse to auto format that section. > > > > 4. In StatsEvent.java:37 the mSubEvents should have been a Map instead > > of a Vector so we can look up by name easily. Please open a ticket for > > this, or feel free to include it in the next patch. > > > > 5. In CrossCertPairSubsystem.java:191,405 the code will throw an > > exception if getConn() returns null. Instead of checking for the return > > value in all invocations, it would be better to do it inside getConn() > > itself. > > > > Ideally the LdapBoundConnFactory.getConn() should throw an exception if > > it cannot create a connection. > > > > 6. In HttpPKIMessage.java:77 instead of checking for null return value > > it might be better to change the RequestTransfer > > .getTransferAttributes() to always return an array (which could be empty > > but not null) like this: > > > > return v.toArray(new String[v.size()]); > > > > This way the change in RequestTransfer.java:110 is no longer needed. > > > > 7. There's a typo in DBRegistry.java:460. To be consistent it should > > throw EDBException. The message should be added into > > base/common/src/UserMessages.properties, something like this: > > > > CMS_DBS_MISSING_OBJECT_CLASS=Missing object class > > > > While you're at it.. :) the code in 472-481 could be simplified into: > > > > String[] s = attr.getStringValueArray(); > > > > Feel free to include it in your next patch or just file a ticket. > > > > 8. The LdapPredicateParser.nextToken() should never return null, so > > instead of checking the return value you can throw the exception in line > > 330. > > > > Same thing with PolicyPredicateParser.java:331. > > > > 9. In PublisherProcessor.java:495,539 instead of checking for null > > getType(), the comparison can be changed like this: > > > > publishingType.equals(rule.getType()) > > > > Also the loop itself can be simplified as follows: > > > > Enumeration e = mRuleInsts.elements(); > > while (e.hasMoreElements()) { > > LdapRule rule = (LdapRule)e.nextElement(); > > ... > > } > > > > This way we don't need to worry about null name (which shouldn't happen > > anyway) so getRules() won't need to return null. > > > > 10. In LogSubsystem.java:206 the code was changed from catching > > EBaseException to catching all Exception. Any reason for that? This > > might be too broad, we should let real errors (e.g. RuntimeException) be > > handled by the caller. You can leave the e.printStackTrace() there if > > you want. > > > > 11. In CertificateInfo.java:197 if sigAlgId == null and algm == null it > > will not create new AlgorithmId so the sigAlgId will remain null, which > > is not what we want. The original code would have thrown an Exception. I > > think you should check the KeyCertUtil.getSigningAlgorithm() in line > > 191, if it returns null you should throw NoSuchAlgorithmException. > > > > 12. Similar to #5, in UGSubsystem.java instead of checking each > > getConn() invocation you can check it inside getConn() itself and throw > > the exception there. > > > > 13. In EnrollmentService.java:738,791 you should use user message > > CMS_BASE_CERT_NOT_FOUND. The message itself in UserMessages.properties > > should be changed to: > > > > Certificate not found or invalid > > > > Similarly, ideally the getExtDataInCertInfoArray() should throw an > > exception on invalid data. > > > > 14. In HttpMessage.java:120 the readLine() will return null if it > > reaches EOF. There's already a code there to detect this, but I'm not > > sure why it was commented out. I think we should uncomment it. > > > > 15. In PrettyPrintFormat.toHexString() the original code would throw an > > exception if the input byte array is empty. In the new code it will > > return a string that contain indentations only (line 122). Also there's > > still a possibility of an exception in line 115 if in == null and > > lineLen == 0. > > > > It might be better to just check the array at the beginning of the > > method and throw an exception. Or don't change anything, it will throw > > an exception too. Was this problem reported by Coverity as NULL_RETURNS? > > I don't see any method returning null value here. > > > > 16. In KeyUsageExtension.java:213 the original constructor will fail if > > it couldn't get the bitString from the value. Now it will construct the > > KeyUsageExtension with null bitString. It might be better to check the > > return value of getUnalignedBitString() and throw IOException("Invalid > > bit string") or something like that. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0010-Fixes-for-Null_Returns-Cases-1-For-Commit.patch Type: text/x-patch Size: 33149 bytes Desc: not available URL: From akoneru at redhat.com Tue Jun 5 16:23:08 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 05 Jun 2012 12:23:08 -0400 Subject: [Pki-devel] [PATCH]10-3 Fixes for Some of the Coverity Issues under NULL_RETURNS category for Dog Tag 10 for review and commit In-Reply-To: <1338840646.16140.7.camel@abhishek> References: <1338503155.8316.7.camel@abhishek> <4FC8F9DC.2040803@redhat.com> <1338835399.16140.3.camel@abhishek> <1338840646.16140.7.camel@abhishek> Message-ID: <1338913388.32276.1.camel@abhishek> Please find attached [PATCH] [10-3] for review. Regards, Abhishsek Koneru On Mon, 2012-06-04 at 16:10 -0400, Abhishek Koneru wrote: > Please find attached the patch with fixes for issues in the previous > patch[#10] for review. > > --Abhishek Koneru > > On Mon, 2012-06-04 at 14:43 -0400, Abhishek Koneru wrote: > > Please find attached the fixes addressing all the review comments. > > The build passed the smoke test. > > > > Regards, > > Abhishek Koneru > > > > On Fri, 2012-06-01 at 12:20 -0500, Endi Sukma Dewata wrote: > > > On 5/31/2012 5:25 PM, Abhishek Koneru wrote: > > > > Please find attached the patch with fixes for some 40-50 defects of type > > > > NULL_RETURNS in Coverity for Dog Tag 10. > > > > Please review the patch > > > > The build passed Smoke Test. > > > > > > Generally in Java a method should throw an exception if it encounters an > > > error so the caller can know what the problem is and can handle it > > > properly. A method should return null only if it couldn't find the > > > object it's looking for. Some of the current code are doing this in > > > C-style, returning null on error, so the caller will have to explicitly > > > handle it. Fixing this behavior will require a major change, so for now > > > we'd have to stick with the current behavior, but we should have a > > > discussion about this. > > > > > > 1. In CAService.java:1503 the serialNoArray could be null if the serial > > > number is not found or invalid. The exception message should say that > > > too. To be consistent it should throw ECAException with user message > > > CMS_CA_MISSING_SERIAL_NUMBER. > > > > > > Ideally the getExtDataInBigIntegerArray() should throw an exception on > > > invalid data. > > > > > > 2. In CRLIssuingPoint.java:1929,1949 the original code would throw an > > > exception if the return value is null. The new code logs the error but > > > continues processing the next request. I think they should throw an > > > exception like in #1. Or, if the error is supposed to be ignored, please > > > add a comment there. > > > > > > Ideally the getExtDataInRevokedCertArray() should throw an exception on > > > invalid data. > > > > > > 3. In CRLIssuingPoint.java:1949-1957 the code needs to be formatted > > > properly. You can use Eclipse to auto format that section. > > > > > > 4. In StatsEvent.java:37 the mSubEvents should have been a Map instead > > > of a Vector so we can look up by name easily. Please open a ticket for > > > this, or feel free to include it in the next patch. > > > > > > 5. In CrossCertPairSubsystem.java:191,405 the code will throw an > > > exception if getConn() returns null. Instead of checking for the return > > > value in all invocations, it would be better to do it inside getConn() > > > itself. > > > > > > Ideally the LdapBoundConnFactory.getConn() should throw an exception if > > > it cannot create a connection. > > > > > > 6. In HttpPKIMessage.java:77 instead of checking for null return value > > > it might be better to change the RequestTransfer > > > .getTransferAttributes() to always return an array (which could be empty > > > but not null) like this: > > > > > > return v.toArray(new String[v.size()]); > > > > > > This way the change in RequestTransfer.java:110 is no longer needed. > > > > > > 7. There's a typo in DBRegistry.java:460. To be consistent it should > > > throw EDBException. The message should be added into > > > base/common/src/UserMessages.properties, something like this: > > > > > > CMS_DBS_MISSING_OBJECT_CLASS=Missing object class > > > > > > While you're at it.. :) the code in 472-481 could be simplified into: > > > > > > String[] s = attr.getStringValueArray(); > > > > > > Feel free to include it in your next patch or just file a ticket. > > > > > > 8. The LdapPredicateParser.nextToken() should never return null, so > > > instead of checking the return value you can throw the exception in line > > > 330. > > > > > > Same thing with PolicyPredicateParser.java:331. > > > > > > 9. In PublisherProcessor.java:495,539 instead of checking for null > > > getType(), the comparison can be changed like this: > > > > > > publishingType.equals(rule.getType()) > > > > > > Also the loop itself can be simplified as follows: > > > > > > Enumeration e = mRuleInsts.elements(); > > > while (e.hasMoreElements()) { > > > LdapRule rule = (LdapRule)e.nextElement(); > > > ... > > > } > > > > > > This way we don't need to worry about null name (which shouldn't happen > > > anyway) so getRules() won't need to return null. > > > > > > 10. In LogSubsystem.java:206 the code was changed from catching > > > EBaseException to catching all Exception. Any reason for that? This > > > might be too broad, we should let real errors (e.g. RuntimeException) be > > > handled by the caller. You can leave the e.printStackTrace() there if > > > you want. > > > > > > 11. In CertificateInfo.java:197 if sigAlgId == null and algm == null it > > > will not create new AlgorithmId so the sigAlgId will remain null, which > > > is not what we want. The original code would have thrown an Exception. I > > > think you should check the KeyCertUtil.getSigningAlgorithm() in line > > > 191, if it returns null you should throw NoSuchAlgorithmException. > > > > > > 12. Similar to #5, in UGSubsystem.java instead of checking each > > > getConn() invocation you can check it inside getConn() itself and throw > > > the exception there. > > > > > > 13. In EnrollmentService.java:738,791 you should use user message > > > CMS_BASE_CERT_NOT_FOUND. The message itself in UserMessages.properties > > > should be changed to: > > > > > > Certificate not found or invalid > > > > > > Similarly, ideally the getExtDataInCertInfoArray() should throw an > > > exception on invalid data. > > > > > > 14. In HttpMessage.java:120 the readLine() will return null if it > > > reaches EOF. There's already a code there to detect this, but I'm not > > > sure why it was commented out. I think we should uncomment it. > > > > > > 15. In PrettyPrintFormat.toHexString() the original code would throw an > > > exception if the input byte array is empty. In the new code it will > > > return a string that contain indentations only (line 122). Also there's > > > still a possibility of an exception in line 115 if in == null and > > > lineLen == 0. > > > > > > It might be better to just check the array at the beginning of the > > > method and throw an exception. Or don't change anything, it will throw > > > an exception too. Was this problem reported by Coverity as NULL_RETURNS? > > > I don't see any method returning null value here. > > > > > > 16. In KeyUsageExtension.java:213 the original constructor will fail if > > > it couldn't get the bitString from the value. Now it will construct the > > > KeyUsageExtension with null bitString. It might be better to check the > > > return value of getUnalignedBitString() and throw IOException("Invalid > > > bit string") or something like that. > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0010-3-Fixes-for-NULL_RETURN-cases-review-comments.patch Type: text/x-patch Size: 8197 bytes Desc: not available URL: From akoneru at redhat.com Tue Jun 5 19:18:39 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 05 Jun 2012 15:18:39 -0400 Subject: [Pki-devel] [PATCH]10-4 -- Minor Fix in [PATCH] 10-3 In-Reply-To: <1338913388.32276.1.camel@abhishek> References: <1338503155.8316.7.camel@abhishek> <4FC8F9DC.2040803@redhat.com> <1338835399.16140.3.camel@abhishek> <1338840646.16140.7.camel@abhishek> <1338913388.32276.1.camel@abhishek> Message-ID: <1338923919.32276.4.camel@abhishek> Please find attached a patch with a minor fix in CertificateInfo class for review. Regards, Abhishek Koneru On Tue, 2012-06-05 at 12:23 -0400, Abhishek Koneru wrote: > Please find attached [PATCH] [10-3] for review. > > Regards, > Abhishsek Koneru > > On Mon, 2012-06-04 at 16:10 -0400, Abhishek Koneru wrote: > > Please find attached the patch with fixes for issues in the previous > > patch[#10] for review. > > > > --Abhishek Koneru > > > > On Mon, 2012-06-04 at 14:43 -0400, Abhishek Koneru wrote: > > > Please find attached the fixes addressing all the review comments. > > > The build passed the smoke test. > > > > > > Regards, > > > Abhishek Koneru > > > > > > On Fri, 2012-06-01 at 12:20 -0500, Endi Sukma Dewata wrote: > > > > On 5/31/2012 5:25 PM, Abhishek Koneru wrote: > > > > > Please find attached the patch with fixes for some 40-50 defects of type > > > > > NULL_RETURNS in Coverity for Dog Tag 10. > > > > > Please review the patch > > > > > The build passed Smoke Test. > > > > > > > > Generally in Java a method should throw an exception if it encounters an > > > > error so the caller can know what the problem is and can handle it > > > > properly. A method should return null only if it couldn't find the > > > > object it's looking for. Some of the current code are doing this in > > > > C-style, returning null on error, so the caller will have to explicitly > > > > handle it. Fixing this behavior will require a major change, so for now > > > > we'd have to stick with the current behavior, but we should have a > > > > discussion about this. > > > > > > > > 1. In CAService.java:1503 the serialNoArray could be null if the serial > > > > number is not found or invalid. The exception message should say that > > > > too. To be consistent it should throw ECAException with user message > > > > CMS_CA_MISSING_SERIAL_NUMBER. > > > > > > > > Ideally the getExtDataInBigIntegerArray() should throw an exception on > > > > invalid data. > > > > > > > > 2. In CRLIssuingPoint.java:1929,1949 the original code would throw an > > > > exception if the return value is null. The new code logs the error but > > > > continues processing the next request. I think they should throw an > > > > exception like in #1. Or, if the error is supposed to be ignored, please > > > > add a comment there. > > > > > > > > Ideally the getExtDataInRevokedCertArray() should throw an exception on > > > > invalid data. > > > > > > > > 3. In CRLIssuingPoint.java:1949-1957 the code needs to be formatted > > > > properly. You can use Eclipse to auto format that section. > > > > > > > > 4. In StatsEvent.java:37 the mSubEvents should have been a Map instead > > > > of a Vector so we can look up by name easily. Please open a ticket for > > > > this, or feel free to include it in the next patch. > > > > > > > > 5. In CrossCertPairSubsystem.java:191,405 the code will throw an > > > > exception if getConn() returns null. Instead of checking for the return > > > > value in all invocations, it would be better to do it inside getConn() > > > > itself. > > > > > > > > Ideally the LdapBoundConnFactory.getConn() should throw an exception if > > > > it cannot create a connection. > > > > > > > > 6. In HttpPKIMessage.java:77 instead of checking for null return value > > > > it might be better to change the RequestTransfer > > > > .getTransferAttributes() to always return an array (which could be empty > > > > but not null) like this: > > > > > > > > return v.toArray(new String[v.size()]); > > > > > > > > This way the change in RequestTransfer.java:110 is no longer needed. > > > > > > > > 7. There's a typo in DBRegistry.java:460. To be consistent it should > > > > throw EDBException. The message should be added into > > > > base/common/src/UserMessages.properties, something like this: > > > > > > > > CMS_DBS_MISSING_OBJECT_CLASS=Missing object class > > > > > > > > While you're at it.. :) the code in 472-481 could be simplified into: > > > > > > > > String[] s = attr.getStringValueArray(); > > > > > > > > Feel free to include it in your next patch or just file a ticket. > > > > > > > > 8. The LdapPredicateParser.nextToken() should never return null, so > > > > instead of checking the return value you can throw the exception in line > > > > 330. > > > > > > > > Same thing with PolicyPredicateParser.java:331. > > > > > > > > 9. In PublisherProcessor.java:495,539 instead of checking for null > > > > getType(), the comparison can be changed like this: > > > > > > > > publishingType.equals(rule.getType()) > > > > > > > > Also the loop itself can be simplified as follows: > > > > > > > > Enumeration e = mRuleInsts.elements(); > > > > while (e.hasMoreElements()) { > > > > LdapRule rule = (LdapRule)e.nextElement(); > > > > ... > > > > } > > > > > > > > This way we don't need to worry about null name (which shouldn't happen > > > > anyway) so getRules() won't need to return null. > > > > > > > > 10. In LogSubsystem.java:206 the code was changed from catching > > > > EBaseException to catching all Exception. Any reason for that? This > > > > might be too broad, we should let real errors (e.g. RuntimeException) be > > > > handled by the caller. You can leave the e.printStackTrace() there if > > > > you want. > > > > > > > > 11. In CertificateInfo.java:197 if sigAlgId == null and algm == null it > > > > will not create new AlgorithmId so the sigAlgId will remain null, which > > > > is not what we want. The original code would have thrown an Exception. I > > > > think you should check the KeyCertUtil.getSigningAlgorithm() in line > > > > 191, if it returns null you should throw NoSuchAlgorithmException. > > > > > > > > 12. Similar to #5, in UGSubsystem.java instead of checking each > > > > getConn() invocation you can check it inside getConn() itself and throw > > > > the exception there. > > > > > > > > 13. In EnrollmentService.java:738,791 you should use user message > > > > CMS_BASE_CERT_NOT_FOUND. The message itself in UserMessages.properties > > > > should be changed to: > > > > > > > > Certificate not found or invalid > > > > > > > > Similarly, ideally the getExtDataInCertInfoArray() should throw an > > > > exception on invalid data. > > > > > > > > 14. In HttpMessage.java:120 the readLine() will return null if it > > > > reaches EOF. There's already a code there to detect this, but I'm not > > > > sure why it was commented out. I think we should uncomment it. > > > > > > > > 15. In PrettyPrintFormat.toHexString() the original code would throw an > > > > exception if the input byte array is empty. In the new code it will > > > > return a string that contain indentations only (line 122). Also there's > > > > still a possibility of an exception in line 115 if in == null and > > > > lineLen == 0. > > > > > > > > It might be better to just check the array at the beginning of the > > > > method and throw an exception. Or don't change anything, it will throw > > > > an exception too. Was this problem reported by Coverity as NULL_RETURNS? > > > > I don't see any method returning null value here. > > > > > > > > 16. In KeyUsageExtension.java:213 the original constructor will fail if > > > > it couldn't get the bitString from the value. Now it will construct the > > > > KeyUsageExtension with null bitString. It might be better to check the > > > > return value of getUnalignedBitString() and throw IOException("Invalid > > > > bit string") or something like that. > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0010-4-Fixes-for-NULL_RETURN-cases-review-comments.patch Type: text/x-patch Size: 1784 bytes Desc: not available URL: From edewata at redhat.com Tue Jun 5 19:49:24 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 05 Jun 2012 14:49:24 -0500 Subject: [Pki-devel] [PATCH]10-4 -- Minor Fix in [PATCH] 10-3 In-Reply-To: <1338923919.32276.4.camel@abhishek> References: <1338503155.8316.7.camel@abhishek> <4FC8F9DC.2040803@redhat.com> <1338835399.16140.3.camel@abhishek> <1338840646.16140.7.camel@abhishek> <1338913388.32276.1.camel@abhishek> <1338923919.32276.4.camel@abhishek> Message-ID: <4FCE62C4.8030308@redhat.com> On 6/5/2012 2:18 PM, Abhishek Koneru wrote: > Please find attached a patch with a minor fix in CertificateInfo class > for review. ACK 10-2, 10-3, 10-4. Pushed to master. -- Endi S. Dewata From Joshua.Roys at gtri.gatech.edu Tue Jun 5 20:35:32 2012 From: Joshua.Roys at gtri.gatech.edu (Joshua Roys) Date: Tue, 5 Jun 2012 16:35:32 -0400 Subject: [Pki-devel] [PATCH] Add LDAP cert publisher using LDAP auth DN Message-ID: <4FCE6D94.9030905@gtri.gatech.edu> Hello, Attached is a patch that I've just tested locally to publish certs to a LDAP directory easily if you have also setup authentication for user certs using LDAP. I noticed an attribute stored in the internal db which was the full DN of the authenticated user and that's what this uses. (I also specify a predicate on the publish rule of profileId==caDirUserDualCert to restrict the candidate certs to the proper set.) Thanks, Josh -------------- next part -------------- From 53b1ddf9a2e58138eb4e2d132a6df6a67f6d8ee0 Mon Sep 17 00:00:00 2001 From: Joshua Roys Date: Tue, 5 Jun 2012 16:03:26 -0400 Subject: [PATCH] Add LDAP cert publisher using LDAP auth DN If LDAP authentication is used to submit certificate profiles, the DN used to authenticate the request is saved. Use that DN when publishing certs back out to the same LDAP directory. --- base/common/src/CMakeLists.txt | 1 + .../cms/publish/mappers/LdapAuthNameMap.java | 192 ++++++++++++++++++++ 2 files changed, 193 insertions(+), 0 deletions(-) create mode 100644 base/common/src/com/netscape/cms/publish/mappers/LdapAuthNameMap.java diff --git a/base/common/src/CMakeLists.txt b/base/common/src/CMakeLists.txt index 0a9fcdd..97e62bb 100644 --- a/base/common/src/CMakeLists.txt +++ b/base/common/src/CMakeLists.txt @@ -433,6 +433,7 @@ set(pki-cms_java_SRCS com/netscape/cms/publish/mappers/LdapCrlIssuerCompsMap.java com/netscape/cms/publish/mappers/LdapDNCompsMap.java com/netscape/cms/publish/mappers/LdapSimpleMap.java + com/netscape/cms/publish/mappers/LdapAuthNameMap.java com/netscape/cms/publish/publishers/LdapEncryptCertPublisher.java com/netscape/cms/publish/publishers/LdapUserCertPublisher.java com/netscape/cms/publish/publishers/LdapCaCertPublisher.java diff --git a/base/common/src/com/netscape/cms/publish/mappers/LdapAuthNameMap.java b/base/common/src/com/netscape/cms/publish/mappers/LdapAuthNameMap.java new file mode 100644 index 0000000..6238cc4 --- /dev/null +++ b/base/common/src/com/netscape/cms/publish/mappers/LdapAuthNameMap.java @@ -0,0 +1,192 @@ +// --- BEGIN COPYRIGHT BLOCK --- +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// This program is distributed in the hope that it will be useful, +// but WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +// GNU General Public License for more details. +// +// You should have received a copy of the GNU General Public License along +// with this program; if not, write to the Free Software Foundation, Inc., +// 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +// +// (C) 2012 Red Hat, Inc. +// All rights reserved. +// --- END COPYRIGHT BLOCK --- +package com.netscape.cms.publish.mappers; + +import java.io.IOException; +import java.security.cert.X509Certificate; +import java.util.Locale; +import java.util.Vector; + +import netscape.ldap.LDAPConnection; +import netscape.ldap.LDAPEntry; +import netscape.ldap.LDAPException; +import netscape.ldap.LDAPSearchResults; +import netscape.ldap.LDAPv2; +import netscape.ldap.LDAPv3; + +import com.netscape.certsrv.apps.CMS; +import com.netscape.certsrv.base.EBaseException; +import com.netscape.certsrv.base.IConfigStore; +import com.netscape.certsrv.base.IExtendedPluginInfo; +import com.netscape.certsrv.ldap.ELdapException; +import com.netscape.certsrv.ldap.ELdapServerDownException; +import com.netscape.certsrv.logging.ILogger; +import com.netscape.certsrv.profile.IProfileAuthenticator; +import com.netscape.certsrv.publish.ILdapMapper; +import com.netscape.certsrv.request.IRequest; + +/** + * Maps a request to an entry in the LDAP server. + * This mapper requires LDAP authentication to be used to submit a profile. + * Grab the extdata-authenticatedName from the request and use that as the DN. + * + * @version $Revision$, $Date$ + */ +public class LdapAuthNameMap implements ILdapMapper, IExtendedPluginInfo { + private ILogger mLogger = CMS.getLogger(); + protected IConfigStore mConfig = null; + + /** + * Constructor. + */ + public LdapAuthNameMap() { + } + + public String[] getExtendedPluginInfo(Locale locale) { + String params[] = { + IExtendedPluginInfo.HELP_TOKEN + ";configuration-ldappublish-mapper-simplemapper", + IExtendedPluginInfo.HELP_TEXT + ";This mapper requires LDAP authentication to be used to submit a " + + "profile." + }; + + return params; + } + + public IConfigStore getConfigStore() { + return mConfig; + } + + /** + * for initializing from config store. + */ + public void init(IConfigStore config) + throws EBaseException { + mConfig = config; + } + + /** + * Maps a X500 subject name to LDAP entry. + * + * @param conn the LDAP connection. + * @param obj the object to map. + * @exception ELdapException if any LDAP exceptions occured. + */ + public String map(LDAPConnection conn, Object obj) + throws ELdapException { + return map(conn, null, obj); + } + + /** + * Maps a X500 subject name to LDAP entry. + * + * @param conn the LDAP connection. + * @param req the request to map. + * @param obj the object to map. + * @exception ELdapException if any LDAP exceptions occured. + */ + public String map(LDAPConnection conn, IRequest req, Object obj) + throws ELdapException { + if (conn == null) + return null; + String dn = null; + + try { + dn = req.getExtDataInString(IProfileAuthenticator.AUTHENTICATED_NAME); + if (dn == null) { + log(ILogger.LL_FAILURE, CMS.getLogMessage("PUBLISH_DN_NOT_FORMED")); + String s1 = ""; + + if (req != null) + s1 = req.getRequestId().toString(); + throw new ELdapException( + CMS.getUserMessage("CMS_LDAP_NO_DN_MATCH", s1)); + } + int scope = LDAPv2.SCOPE_BASE; + String filter = "(objectclass=*)"; + + // search for entry + String[] attrs = new String[] { LDAPv3.NO_ATTRS }; + + log(ILogger.LL_INFO, "searching for dn: " + dn + " filter:" + + filter + " scope: base"); + + LDAPSearchResults results = + conn.search(dn, scope, filter, attrs, false); + LDAPEntry entry = results.next(); + + if (results.hasMoreElements()) { + log(ILogger.LL_FAILURE, CMS.getLogMessage("PUBLISH_MORE_THAN_ONE_ENTRY", dn, ((req == null) ? "" : + req.getRequestId().toString()))); + throw new ELdapException(CMS.getUserMessage("CMS_LDAP_MORE_THAN_ONE_ENTRY", + ((req == null) ? "" : req.getRequestId().toString()))); + } + if (entry != null) + return entry.getDN(); + else { + log(ILogger.LL_FAILURE, + CMS.getLogMessage("PUBLISH_ENTRY_NOT_FOUND", dn, ((req == null) ? "" : req.getRequestId() + .toString()))); + throw new ELdapException(CMS.getUserMessage("CMS_LDAP_NO_MATCH_FOUND", + "null entry")); + } + } catch (ELdapException e) { + throw e; + } catch (LDAPException e) { + if (e.getLDAPResultCode() == LDAPException.UNAVAILABLE) { + // need to intercept this because message from LDAP is + // "DSA is unavailable" which confuses with DSA PKI. + log(ILogger.LL_FAILURE, + CMS.getLogMessage("PUBLISH_NO_LDAP_SERVER")); + throw new ELdapServerDownException(CMS.getUserMessage("CMS_LDAP_SERVER_UNAVAILABLE", conn.getHost(), "" + + conn.getPort())); + } else { + log(ILogger.LL_FAILURE, CMS.getLogMessage("PUBLISH_DN_MAP_EXCEPTION", "", e.toString())); + throw new ELdapException(CMS.getUserMessage("CMS_LDAP_NO_MATCH_FOUND", e.toString())); + } + } catch (EBaseException e) { + log(ILogger.LL_FAILURE, CMS.getLogMessage("PUBLISH_EXCEPTION_CAUGHT", e.toString())); + throw new ELdapException(CMS.getUserMessage("CMS_LDAP_NO_MATCH_FOUND", e.toString())); + } + } + + public String getImplName() { + return "LdapAuthNameMap"; + } + + public String getDescription() { + return "LdapAuthNameMap"; + } + + public Vector getDefaultParams() { + Vector v = new Vector(); + + return v; + } + + public Vector getInstanceParams() { + Vector v = new Vector(); + + return v; + } + + private void log(int level, String msg) { + mLogger.log(ILogger.EV_SYSTEM, ILogger.S_LDAP, level, + "LdapAuthNameMap: " + msg); + } + +} -- 1.7.4.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5046 bytes Desc: S/MIME Cryptographic Signature URL: From edewata at redhat.com Thu Jun 7 14:28:37 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 07 Jun 2012 09:28:37 -0500 Subject: [Pki-devel] [PATCH] 65 Added cert revocation REST service. Message-ID: <4FD0BA95.5030503@redhat.com> The cert revocation REST service is based on DoRevoke and DoUnrevoke servlets. It provides an interface to manage certificate revocation. Ticket #161 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0065-Added-cert-revocation-REST-service.patch Type: text/x-patch Size: 91190 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 7 14:28:48 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 07 Jun 2012 09:28:48 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. Message-ID: <4FD0BAA0.4020600@redhat.com> The cert revocation CLI provides a tool to revoke and unrevoke certificates. Ticket #161 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0066-Added-cert-revocation-CLI.patch Type: text/x-patch Size: 23487 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 7 14:29:02 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 07 Jun 2012 09:29:02 -0500 Subject: [Pki-devel] [PATCH] 67 Added REST error handler. Message-ID: <4FD0BAAE.80907@redhat.com> If a REST method returns a Response object it has to be handled manually. A new getEntity() method has been added to obtain the entity from the Response object and also map HTTP errors into exceptions. Ticket #161 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0067-Added-REST-error-handler.patch Type: text/x-patch Size: 7352 bytes Desc: not available URL: From awnuk at redhat.com Thu Jun 7 16:38:25 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Thu, 07 Jun 2012 09:38:25 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD0BAA0.4020600@redhat.com> References: <4FD0BAA0.4020600@redhat.com> Message-ID: <4FD0D901.1020801@redhat.com> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: > The cert revocation CLI provides a tool to revoke and unrevoke > certificates. "unrevoke" is really inappropriate term. It suggests that one could unrevoke any revoked certificate where is fact one can only take off hold certificates that are currently on hold. > > Ticket #161 > > > > _______________________________________________ > 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 Thu Jun 7 21:04:59 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 07 Jun 2012 16:04:59 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD0D901.1020801@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> Message-ID: <4FD1177B.9040904@redhat.com> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: > On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >> The cert revocation CLI provides a tool to revoke and unrevoke >> certificates. > > "unrevoke" is really inappropriate term. It suggests that one could > unrevoke any revoked certificate where is fact one can only take off > hold certificates that are currently on hold. How about a "revoke" command for permanent revocation only, and separate "on-hold" and "off-hold" commands for temporary revocation? Any suggestions? -- Endi S. Dewata From awnuk at redhat.com Fri Jun 8 18:12:42 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Fri, 08 Jun 2012 11:12:42 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD1177B.9040904@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> Message-ID: <4FD2409A.9040701@redhat.com> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: > On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>> The cert revocation CLI provides a tool to revoke and unrevoke >>> certificates. >> >> "unrevoke" is really inappropriate term. It suggests that one could >> unrevoke any revoked certificate where is fact one can only take off >> hold certificates that are currently on hold. > > How about a "revoke" command for permanent revocation only, and > separate "on-hold" and "off-hold" commands for temporary revocation? > Any suggestions? > This is asymmetric case. "on-hold" is just one of many revocation reasons. Certificate can be taken off hold if it was revoked with "on-hold" reason. There are only two operations: certificate revocation and taking certificates off hold. Andrew From edewata at redhat.com Fri Jun 8 19:06:21 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Jun 2012 14:06:21 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD2409A.9040701@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> Message-ID: <4FD24D2D.7000707@redhat.com> On 6/8/2012 1:12 PM, Andrew Wnuk wrote: > On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>> certificates. >>> >>> "unrevoke" is really inappropriate term. It suggests that one could >>> unrevoke any revoked certificate where is fact one can only take off >>> hold certificates that are currently on hold. >> >> How about a "revoke" command for permanent revocation only, and >> separate "on-hold" and "off-hold" commands for temporary revocation? >> Any suggestions? >> > This is asymmetric case. "on-hold" is just one of many revocation > reasons. Certificate can be taken off hold if it was revoked with > "on-hold" reason. There are only two operations: certificate revocation > and taking certificates off hold. The original "revoke" operation is partially asymmetric (permanent revocation) and partially symmetric (temporarily on-hold). It might be more intuitive to create a new "revoke" command that does asymmetric operation only (no "unrevoke" operation) and separate "on-hold" and "off-hold" commands for the symmetric operations. If we only have "revoke" and "off-hold" only, people might be thinking, there's an "off-hold" command, so how do I "hold" a cert? It might not be very obvious that the "revoke" command has an "on-hold" option which behaves differently from the other revoke reasons. -- Endi S. Dewata From nkinder at redhat.com Fri Jun 8 19:19:37 2012 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 08 Jun 2012 12:19:37 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD24D2D.7000707@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> Message-ID: <4FD25049.7010003@redhat.com> On 06/08/2012 12:06 PM, Endi Sukma Dewata wrote: > On 6/8/2012 1:12 PM, Andrew Wnuk wrote: >> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >>> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>>> certificates. >>>> >>>> "unrevoke" is really inappropriate term. It suggests that one could >>>> unrevoke any revoked certificate where is fact one can only take off >>>> hold certificates that are currently on hold. >>> >>> How about a "revoke" command for permanent revocation only, and >>> separate "on-hold" and "off-hold" commands for temporary revocation? >>> Any suggestions? >>> >> This is asymmetric case. "on-hold" is just one of many revocation >> reasons. Certificate can be taken off hold if it was revoked with >> "on-hold" reason. There are only two operations: certificate revocation >> and taking certificates off hold. > > The original "revoke" operation is partially asymmetric (permanent > revocation) and partially symmetric (temporarily on-hold). It might be > more intuitive to create a new "revoke" command that does asymmetric > operation only (no "unrevoke" operation) and separate "on-hold" and > "off-hold" commands for the symmetric operations. > > If we only have "revoke" and "off-hold" only, people might be > thinking, there's an "off-hold" command, so how do I "hold" a cert? It > might not be very obvious that the "revoke" command has an "on-hold" > option which behaves differently from the other revoke reasons. > I tend to agree from a pure CLI perspective. Behind the scenes, "on-hold" is really a revocation reason, but that doesn't mean we need to make the CLI use the exact same terminology. How about having "revoke", "on-hold", and "off-hold" commands? We can still allow one to use the "revoke" command and specify the revocation reason as on-hold, which would be the equivalent of the "on-hold" command. From akoneru at redhat.com Fri Jun 8 21:53:11 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 08 Jun 2012 17:53:11 -0400 Subject: [Pki-devel] [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review Message-ID: <1339192391.25195.2.camel@abhishek> Please find attached [PATCH 11] with fixes for Coverity issues of category NULL RETURNS for DogTag 10. The build passed smoke test. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0011-Fixes-for-NULL_RETURNS-Coverity-Issues-Part-2.patch Type: text/x-patch Size: 45573 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 8 23:37:54 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 08 Jun 2012 18:37:54 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD25049.7010003@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> Message-ID: <4FD28CD2.1080906@redhat.com> On 6/8/2012 2:19 PM, Nathan Kinder wrote: > On 06/08/2012 12:06 PM, Endi Sukma Dewata wrote: >> On 6/8/2012 1:12 PM, Andrew Wnuk wrote: >>> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >>>> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>>>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>>>> certificates. >>>>> >>>>> "unrevoke" is really inappropriate term. It suggests that one could >>>>> unrevoke any revoked certificate where is fact one can only take off >>>>> hold certificates that are currently on hold. >>>> >>>> How about a "revoke" command for permanent revocation only, and >>>> separate "on-hold" and "off-hold" commands for temporary revocation? >>>> Any suggestions? >>>> >>> This is asymmetric case. "on-hold" is just one of many revocation >>> reasons. Certificate can be taken off hold if it was revoked with >>> "on-hold" reason. There are only two operations: certificate revocation >>> and taking certificates off hold. >> >> The original "revoke" operation is partially asymmetric (permanent >> revocation) and partially symmetric (temporarily on-hold). It might be >> more intuitive to create a new "revoke" command that does asymmetric >> operation only (no "unrevoke" operation) and separate "on-hold" and >> "off-hold" commands for the symmetric operations. >> >> If we only have "revoke" and "off-hold" only, people might be >> thinking, there's an "off-hold" command, so how do I "hold" a cert? It >> might not be very obvious that the "revoke" command has an "on-hold" >> option which behaves differently from the other revoke reasons. >> > I tend to agree from a pure CLI perspective. Behind the scenes, > "on-hold" is really a revocation reason, but that doesn't mean we need > to make the CLI use the exact same terminology. > > How about having "revoke", "on-hold", and "off-hold" commands? We can > still allow one to use the "revoke" command and specify the revocation > reason as on-hold, which would be the equivalent of the "on-hold" command. +1 Some other possibilities: - revoke/hold/release - revoke/suspend/release - revoke/enable/disable -- Endi S. Dewata From nkinder at redhat.com Fri Jun 8 23:56:00 2012 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 08 Jun 2012 16:56:00 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD28CD2.1080906@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> <4FD28CD2.1080906@redhat.com> Message-ID: <4FD29110.7060403@redhat.com> On 06/08/2012 04:37 PM, Endi Sukma Dewata wrote: > On 6/8/2012 2:19 PM, Nathan Kinder wrote: >> On 06/08/2012 12:06 PM, Endi Sukma Dewata wrote: >>> On 6/8/2012 1:12 PM, Andrew Wnuk wrote: >>>> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >>>>> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>>>>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>>>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>>>>> certificates. >>>>>> >>>>>> "unrevoke" is really inappropriate term. It suggests that one could >>>>>> unrevoke any revoked certificate where is fact one can only take off >>>>>> hold certificates that are currently on hold. >>>>> >>>>> How about a "revoke" command for permanent revocation only, and >>>>> separate "on-hold" and "off-hold" commands for temporary revocation? >>>>> Any suggestions? >>>>> >>>> This is asymmetric case. "on-hold" is just one of many revocation >>>> reasons. Certificate can be taken off hold if it was revoked with >>>> "on-hold" reason. There are only two operations: certificate >>>> revocation >>>> and taking certificates off hold. >>> >>> The original "revoke" operation is partially asymmetric (permanent >>> revocation) and partially symmetric (temporarily on-hold). It might be >>> more intuitive to create a new "revoke" command that does asymmetric >>> operation only (no "unrevoke" operation) and separate "on-hold" and >>> "off-hold" commands for the symmetric operations. >>> >>> If we only have "revoke" and "off-hold" only, people might be >>> thinking, there's an "off-hold" command, so how do I "hold" a cert? It >>> might not be very obvious that the "revoke" command has an "on-hold" >>> option which behaves differently from the other revoke reasons. >>> >> I tend to agree from a pure CLI perspective. Behind the scenes, >> "on-hold" is really a revocation reason, but that doesn't mean we need >> to make the CLI use the exact same terminology. >> >> How about having "revoke", "on-hold", and "off-hold" commands? We can >> still allow one to use the "revoke" command and specify the revocation >> reason as on-hold, which would be the equivalent of the "on-hold" >> command. > > +1 > > Some other possibilities: > - revoke/hold/release I like this one. Maybe even "revoke/hold/release-hold"? Plain "release" doesn't seem very descriptive on it's own. I think "release-hold" is more clear. > - revoke/suspend/release > - revoke/enable/disable > From awnuk at redhat.com Sun Jun 10 21:55:21 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Sun, 10 Jun 2012 14:55:21 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD29110.7060403@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> <4FD28CD2.1080906@redhat.com> <4FD29110.7060403@redhat.com> Message-ID: <4FD517C9.8070101@redhat.com> On 06/08/2012 04:56 PM, Nathan Kinder wrote: > On 06/08/2012 04:37 PM, Endi Sukma Dewata wrote: >> On 6/8/2012 2:19 PM, Nathan Kinder wrote: >>> On 06/08/2012 12:06 PM, Endi Sukma Dewata wrote: >>>> On 6/8/2012 1:12 PM, Andrew Wnuk wrote: >>>>> On 06/07/2012 02:04 PM, Endi Sukma Dewata wrote: >>>>>> On 6/7/2012 11:38 AM, Andrew Wnuk wrote: >>>>>>> On 06/07/2012 07:28 AM, Endi Sukma Dewata wrote: >>>>>>>> The cert revocation CLI provides a tool to revoke and unrevoke >>>>>>>> certificates. >>>>>>> >>>>>>> "unrevoke" is really inappropriate term. It suggests that one could >>>>>>> unrevoke any revoked certificate where is fact one can only take >>>>>>> off >>>>>>> hold certificates that are currently on hold. >>>>>> >>>>>> How about a "revoke" command for permanent revocation only, and >>>>>> separate "on-hold" and "off-hold" commands for temporary revocation? >>>>>> Any suggestions? >>>>>> >>>>> This is asymmetric case. "on-hold" is just one of many revocation >>>>> reasons. Certificate can be taken off hold if it was revoked with >>>>> "on-hold" reason. There are only two operations: certificate >>>>> revocation >>>>> and taking certificates off hold. >>>> >>>> The original "revoke" operation is partially asymmetric (permanent >>>> revocation) and partially symmetric (temporarily on-hold). It might be >>>> more intuitive to create a new "revoke" command that does asymmetric >>>> operation only (no "unrevoke" operation) and separate "on-hold" and >>>> "off-hold" commands for the symmetric operations. >>>> >>>> If we only have "revoke" and "off-hold" only, people might be >>>> thinking, there's an "off-hold" command, so how do I "hold" a cert? It >>>> might not be very obvious that the "revoke" command has an "on-hold" >>>> option which behaves differently from the other revoke reasons. >>>> >>> I tend to agree from a pure CLI perspective. Behind the scenes, >>> "on-hold" is really a revocation reason, but that doesn't mean we need >>> to make the CLI use the exact same terminology. >>> >>> How about having "revoke", "on-hold", and "off-hold" commands? We can >>> still allow one to use the "revoke" command and specify the revocation >>> reason as on-hold, which would be the equivalent of the "on-hold" >>> command. >> >> +1 >> >> Some other possibilities: >> - revoke/hold/release > I like this one. Maybe even "revoke/hold/release-hold"? Plain > "release" doesn't seem very descriptive on it's own. I think > "release-hold" is more clear. >> - revoke/suspend/release >> - revoke/enable/disable >> > "on-hold" and "off-hold" are just two revocation reason values. Official standard names and values are certificateHold (6) and removeFromCRL (8), so I am fine with additional helper functions/commands (for hold and release/remove) as long as revocation will support all standard values for reason parameter including "certificateHold" and "removeFromCRL". CA provides two step revocation to avoid accidental revocation of incorrect certificates. This is important since revocation operation is irreversible (with one exception) and it is specially important to avoid accidental revocation of CA certificate. I do hope that CLI interface provides secure two step revocation including protection against accidental revocation of CA certificate. Andrew From edewata at redhat.com Mon Jun 11 20:47:21 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Jun 2012 15:47:21 -0500 Subject: [Pki-devel] [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review In-Reply-To: <1339192391.25195.2.camel@abhishek> References: <1339192391.25195.2.camel@abhishek> Message-ID: <4FD65959.6040201@redhat.com> On 6/8/2012 4:53 PM, Abhishek Koneru wrote: > Please find attached [PATCH 11] with fixes for Coverity issues of > category NULL RETURNS for DogTag 10. Some issues: 1. The link to JSS jar file should have been /usr/share/java/jss/jss4.jar. This link is created by scripts/dev_setup. 2. In AuthToken.java:303,341,343,390 the code catches the exception and throws a new exception but with the same type and message. This is not necessary and it will change the stack trace information (it will no longer show where the original exception happens). It's better to simply not catch the exception and let it be handled by the caller. There are cases where catch-and-throw make sense. If you want to do something but still want to keep the original stack trace you can re-throw the same exception object (not create a new one): } catch (Exception e) { // do something throw e; } If you want to change the exception type/message you can throw a new exception that wraps the old exception: } catch (OldException e) { throw new NewException(e); // or throw new NewException(e.getMessage()); } Wrapping is possible if the NewException has a constructor that takes the OldException. This is to allow chaining the stack trace. If such constructor is not available at least try to include the original exception message. 3. In CMCAuth.java:877 the exception should throw the CMS_AUTHENTICATION_MANAGER_NOT_FOUND message from UserMessages. 4. Similar to #2, in CMCAuth.java:907 it's not necessary to catch and throw a new exception with the same type/message. 5. While you're at it, in SubjAltNameExt.java:255, the /* of String */ comment can be removed since we're using generics now. 6. In DisplayHtmlServlet.java:65 moving the authenticate() into the try-catch block doesn't seem to be necessary. The authenticate() throws an EBaseException with is already declared by the process(). The try-catch block is intended to deal with template problem, which is not the case with authenticate(). 7. There's a formatting issue in ChallengeRevocationServlet1.java:138. 8. In UpdateCRL.java:123 the authenticate() is moved into a try-catch block which will swallow all exceptions. I think the null return value should be checked before the try-catch block. 9. In LDAPSecurityDomainSessionTable.java:195 you can reuse the LDAPAttribute object obtained for null checking. Also, it would be better to indicate which entry is invalid in the exception message. LDAPAttribute sid = entry.getAttribute("cn"); if (sid == null) { throw new Exception("Invalid LDAP Entry " + entry.getDN() + ". No session id (cn)."); } ret.add(sid.getStringValueArray()[0]); Similarly, add the entry DN into the exception message in line 237. 10. In AuthSubsystem.java:461 you can iterate over hashtable values directly, thus avoiding the lookup operation: for (AuthManagerProxy proxy : mAuthMgrInsts.values()) { IAuthManager mgr = proxy.getAuthManager(); ... } 11. In PasswdUserDBAuthentication.java:188 the getUser() will return null only if there's a problem. However, if you throw an exception in line 190 it will be logged as "UID not found", which is not the case. I think the null checking should be moved after the try-catch block like this: try { user = ug.getUser(uid); } catch (...) { ... } if (user == null) { throw new EInvalidCredentials( CMS.getUserMessage("CMS_AUTHENTICATION_INTERNAL_ERROR", "Failure in User Group subsystem.")); } Ideally the getUser() should throw an exception instead of returning null. That would be fixed under ticket #201. 12. There's a formatting issue in DBSubsystem.java:411. Also, it would be better to include which entry that has a problem: throw new Exception( "Missing attribute " + PROP_NEXT_RANGE + " in entry " + dn); 13. Formatting issue in KeyRepository.java:254. Also, include the serial number in the exception message in line 272: throw new EBaseException( "Failed to recover Key for Serial Number " + serialNo); 14. In ARequestQueue.java:591 the boolean initialization is not necessary because it will be initialized with the return value of serviceRequest(). Also remove the auto-generated TODO comment. 15. In AuthTokenTest.java:122 it might be better to use this message: throw new Exception("Unable to get key2 as Date"); 16. Formatting issue in AuthTokenTest.java:143. 17. In DRMTool.java:1645 the readLine() will only return null if the password file is empty, which I suppose is not allowed. So I think it should throw an exception instead of continuing with empty password. 18. Same issue in PKCS12Export.java:227,239 as in #17. 19. In KRAService.java:101 remove the auto-generated TODO message. 20. In RecoveryService.java:200 it might be better to throw EKRAException with user message CMS_KRA_INVALID_KEYRECORD. This may make some other changes unnecessary. 21. As explained in #2, in HTTPClient.java:431,448 you can throw the original exception object. 22. Also like in #2, in HTTPClient.java:1198 you could leave the exception uncaught or throw the original exception object, but remove the auto-generated TODO message in line 1201. 23. In ChallengeException.java:36,45, the original code would have thrown an exception. The new code will continue and return an empty string. It might be better to return the attribute directly and let the caller handle the null value: public StateAttribute getState() { return _res.getAttributeSet().getAttributeByType( Attribute.STATE); } public ReplyMessageAttribute getReplyMessage() { return _res.getAttributeSet().getAttributeByType( Attribute.REPLY_MESSAGE); } 24. Same thing as #23 in RejectException.java:36. 25. In DerInputBuffer.java:58 and DerInputStream.java:117 to be consistent the code should throw an IOException. 26. In IssuingDistributionPointExtension.java:199 add some exception message, for example "Unable to get unaligned bit string." 27. Formatting issue in JSSUtil.java:71-72. Also, the exception message probably should say "Cannot decode the given bytes." -- Endi S. Dewata From edewata at redhat.com Mon Jun 11 22:54:15 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Jun 2012 17:54:15 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD517C9.8070101@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> <4FD28CD2.1080906@redhat.com> <4FD29110.7060403@redhat.com> <4FD517C9.8070101@redhat.com> Message-ID: <4FD67717.9090206@redhat.com> On 6/10/2012 4:55 PM, Andrew Wnuk wrote: > On 06/08/2012 04:56 PM, Nathan Kinder wrote: >>> - revoke/hold/release >> I like this one. Maybe even "revoke/hold/release-hold"? Plain >> "release" doesn't seem very descriptive on it's own. I think >> "release-hold" is more clear. Sounds good. I'll change that in the next patch revision. > "on-hold" and "off-hold" are just two revocation reason values. Official > standard names and values are certificateHold (6) and removeFromCRL (8), > so I am fine with additional helper functions/commands (for hold and > release/remove) as long as revocation will support all standard values > for reason parameter including "certificateHold" and "removeFromCRL". > > CA provides two step revocation to avoid accidental revocation of > incorrect certificates. This is important since revocation operation is > irreversible (with one exception) and it is specially important to avoid > accidental revocation of CA certificate. Do you mean the CA Web UI? In the UI you'd have to go through several pages to find & select the certs and enter the revocation date/reason/comments, but you can still change the inputs in the last (confirmation) page, and once you click Submit the certificate will be revoked immediately, so basically it's still a single step operation. Usually a confirmation page shouldn't allow any input change without navigating to another page first. > I do hope that CLI interface provides secure two step revocation > including protection against accidental revocation of CA certificate. I can change the CLI to ask for a confirmation before executing the operation like this: % pki cert-revoke 0x8 --reason=KEY_COMPROMISE Revoking certificate "0x8". Are you sure (Y/N)? Y ------------------------- Revoked certificate "0x8" ------------------------- And for automation/scripting you can suppress the confirmation: % pki cert-revoke 0x8 --reason=KEY_COMPROMISE --force ------------------------- Revoked certificate "0x8" ------------------------- Is this ok? How about the other add/mod/delete commands, should we confirm each operation that changes the database? -- Endi S. Dewata From awnuk at redhat.com Mon Jun 11 23:30:26 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Mon, 11 Jun 2012 16:30:26 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD67717.9090206@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> <4FD28CD2.1080906@redhat.com> <4FD29110.7060403@redhat.com> <4FD517C9.8070101@redhat.com> <4FD67717.9090206@redhat.com> Message-ID: <4FD67F92.8030609@redhat.com> On 06/11/2012 03:54 PM, Endi Sukma Dewata wrote: > On 6/10/2012 4:55 PM, Andrew Wnuk wrote: >> On 06/08/2012 04:56 PM, Nathan Kinder wrote: >>>> - revoke/hold/release >>> I like this one. Maybe even "revoke/hold/release-hold"? Plain >>> "release" doesn't seem very descriptive on it's own. I think >>> "release-hold" is more clear. > > Sounds good. I'll change that in the next patch revision. > >> "on-hold" and "off-hold" are just two revocation reason values. Official >> standard names and values are certificateHold (6) and removeFromCRL (8), >> so I am fine with additional helper functions/commands (for hold and >> release/remove) as long as revocation will support all standard values >> for reason parameter including "certificateHold" and "removeFromCRL". >> >> CA provides two step revocation to avoid accidental revocation of >> incorrect certificates. This is important since revocation operation is >> irreversible (with one exception) and it is specially important to avoid >> accidental revocation of CA certificate. > > Do you mean the CA Web UI? In the UI you'd have to go through several > pages to find & select the certs and enter the revocation > date/reason/comments, but you can still change the inputs in the last > (confirmation) page, and once you click Submit the certificate will be > revoked immediately, so basically it's still a single step operation. > Usually a confirmation page shouldn't allow any input change without > navigating to another page first. > >> I do hope that CLI interface provides secure two step revocation >> including protection against accidental revocation of CA certificate. > > I can change the CLI to ask for a confirmation before executing the > operation like this: > > % pki cert-revoke 0x8 --reason=KEY_COMPROMISE > Revoking certificate "0x8". > Are you sure (Y/N)? Y > ------------------------- > Revoked certificate "0x8" > ------------------------- You not really after confirmation but verification, so you need more info than just the same serial number. You want to be sure that you are actually revoking correct certificate, so maybe serial number and subject name would be enough. > > And for automation/scripting you can suppress the confirmation: > > % pki cert-revoke 0x8 --reason=KEY_COMPROMISE --force > ------------------------- > Revoked certificate "0x8" > ------------------------- > > Is this ok? How about the other add/mod/delete commands, should we > confirm each operation that changes the database? > From edewata at redhat.com Tue Jun 12 00:44:35 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 11 Jun 2012 19:44:35 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD67F92.8030609@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> <4FD28CD2.1080906@redhat.com> <4FD29110.7060403@redhat.com> <4FD517C9.8070101@redhat.com> <4FD67717.9090206@redhat.com> <4FD67F92.8030609@redhat.com> Message-ID: <4FD690F3.30901@redhat.com> On 6/11/2012 6:30 PM, Andrew Wnuk wrote: >>> I do hope that CLI interface provides secure two step revocation >>> including protection against accidental revocation of CA certificate. >> >> I can change the CLI to ask for a confirmation before executing the >> operation like this: >> >> % pki cert-revoke 0x8 --reason=KEY_COMPROMISE >> Revoking certificate "0x8". >> Are you sure (Y/N)? Y >> ------------------------- >> Revoked certificate "0x8" >> ------------------------- > You not really after confirmation but verification, so you need more > info than just the same serial number. > You want to be sure that you are actually revoking correct certificate, > so maybe serial number and subject name would be enough. Suppose there is a number of certs with the same subject (I'm not sure how common this is), requiring the serial number and the subject name might not be much more helpful than requiring the serial number alone. How about showing the cert info in the confirmation? % pki cert-revoke 0x8 --reason=KEY_COMPROMISE Revoking certificate: Serial Number: 0x8 Issuer: CN=Certificate Authority,O=EXAMPLE-COM Subject: UID=testuser,E=testuser at example.com,CN=Test User Status: VALID Not Before: Mon Jun 11 17:29:44 CDT 2012 Not After: Sat Dec 08 16:29:44 CST 2012 Are you sure (Y/N)? Y ------------------------- Revoked certificate "0x8" ------------------------- In the UI you can search the certs based on other criteria such as subject, issuer, validity, etc. In CLI this can be handled by a separate cert-find command. Once you get the serial number you can use it to call cert-revoke. If you know exactly the serial number you want to revoke, you can skip the cert-find and then call cert-revoke with --force to skip the confirmation. >> Is this ok? How about the other add/mod/delete commands, should we >> confirm each operation that changes the database? Same question, do we need to do the same type of verification/confirmation for other update operations? -- Endi S. Dewata From awnuk at redhat.com Tue Jun 12 18:16:46 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 12 Jun 2012 11:16:46 -0700 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD690F3.30901@redhat.com> References: <4FD0BAA0.4020600@redhat.com> <4FD0D901.1020801@redhat.com> <4FD1177B.9040904@redhat.com> <4FD2409A.9040701@redhat.com> <4FD24D2D.7000707@redhat.com> <4FD25049.7010003@redhat.com> <4FD28CD2.1080906@redhat.com> <4FD29110.7060403@redhat.com> <4FD517C9.8070101@redhat.com> <4FD67717.9090206@redhat.com> <4FD67F92.8030609@redhat.com> <4FD690F3.30901@redhat.com> Message-ID: <4FD7878E.60006@redhat.com> On 06/11/2012 05:44 PM, Endi Sukma Dewata wrote: > On 6/11/2012 6:30 PM, Andrew Wnuk wrote: >>>> I do hope that CLI interface provides secure two step revocation >>>> including protection against accidental revocation of CA certificate. >>> >>> I can change the CLI to ask for a confirmation before executing the >>> operation like this: >>> >>> % pki cert-revoke 0x8 --reason=KEY_COMPROMISE >>> Revoking certificate "0x8". >>> Are you sure (Y/N)? Y >>> ------------------------- >>> Revoked certificate "0x8" >>> ------------------------- > >> You not really after confirmation but verification, so you need more >> info than just the same serial number. >> You want to be sure that you are actually revoking correct certificate, >> so maybe serial number and subject name would be enough. > > Suppose there is a number of certs with the same subject (I'm not sure > how common this is), requiring the serial number and the subject name > might not be much more helpful than requiring the serial number alone. > How about showing the cert info in the confirmation? > > % pki cert-revoke 0x8 --reason=KEY_COMPROMISE > Revoking certificate: > Serial Number: 0x8 > Issuer: CN=Certificate Authority,O=EXAMPLE-COM > Subject: UID=testuser,E=testuser at example.com,CN=Test User > Status: VALID > Not Before: Mon Jun 11 17:29:44 CDT 2012 > Not After: Sat Dec 08 16:29:44 CST 2012 > Are you sure (Y/N)? Y > ------------------------- > Revoked certificate "0x8" > ------------------------- > > In the UI you can search the certs based on other criteria such as > subject, issuer, validity, etc. In CLI this can be handled by a > separate cert-find command. Once you get the serial number you can use > it to call cert-revoke. > > If you know exactly the serial number you want to revoke, you can skip > the cert-find and then call cert-revoke with --force to skip the > confirmation. You should create separate command to handle CA certificate revocation or at least add additional parameter to confirm forcing of CA certificate revocation. > >>> Is this ok? How about the other add/mod/delete commands, should we >>> confirm each operation that changes the database? > > Same question, do we need to do the same type of > verification/confirmation for other update operations? > From akoneru at redhat.com Tue Jun 12 21:48:53 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 12 Jun 2012 17:48:53 -0400 Subject: [Pki-devel] [ PATCH 11-2 ] --- Re: [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review In-Reply-To: <4FD65959.6040201@redhat.com> References: <1339192391.25195.2.camel@abhishek> <4FD65959.6040201@redhat.com> Message-ID: <1339537733.7952.4.camel@abhishek> Submitting patch 11-2 for review. All the comments have been addressed. Build passed the smoke test. Thank you. Regards, Abhishek Koneru On Mon, 2012-06-11 at 15:47 -0500, Endi Sukma Dewata wrote: > On 6/8/2012 4:53 PM, Abhishek Koneru wrote: > > Please find attached [PATCH 11] with fixes for Coverity issues of > > category NULL RETURNS for DogTag 10. > > Some issues: > > 1. The link to JSS jar file should have been > /usr/share/java/jss/jss4.jar. This link is created by scripts/dev_setup. > > 2. In AuthToken.java:303,341,343,390 the code catches the exception and > throws a new exception but with the same type and message. This is not > necessary and it will change the stack trace information (it will no > longer show where the original exception happens). It's better to simply > not catch the exception and let it be handled by the caller. > > There are cases where catch-and-throw make sense. If you want to do > something but still want to keep the original stack trace you can > re-throw the same exception object (not create a new one): > > } catch (Exception e) { > // do something > throw e; > } > > If you want to change the exception type/message you can throw a new > exception that wraps the old exception: > > } catch (OldException e) { > throw new NewException(e); > // or throw new NewException(e.getMessage()); > } > > Wrapping is possible if the NewException has a constructor that takes > the OldException. This is to allow chaining the stack trace. If such > constructor is not available at least try to include the original > exception message. > > 3. In CMCAuth.java:877 the exception should throw the > CMS_AUTHENTICATION_MANAGER_NOT_FOUND message from UserMessages. > > 4. Similar to #2, in CMCAuth.java:907 it's not necessary to catch and > throw a new exception with the same type/message. > > 5. While you're at it, in SubjAltNameExt.java:255, the /* of String */ > comment can be removed since we're using generics now. > > 6. In DisplayHtmlServlet.java:65 moving the authenticate() into the > try-catch block doesn't seem to be necessary. The authenticate() throws > an EBaseException with is already declared by the process(). The > try-catch block is intended to deal with template problem, which is not > the case with authenticate(). > > 7. There's a formatting issue in ChallengeRevocationServlet1.java:138. > > 8. In UpdateCRL.java:123 the authenticate() is moved into a try-catch > block which will swallow all exceptions. I think the null return value > should be checked before the try-catch block. > > 9. In LDAPSecurityDomainSessionTable.java:195 you can reuse the > LDAPAttribute object obtained for null checking. Also, it would be > better to indicate which entry is invalid in the exception message. > > LDAPAttribute sid = entry.getAttribute("cn"); > if (sid == null) { > throw new Exception("Invalid LDAP Entry " + entry.getDN() > + ". No session id (cn)."); > } > ret.add(sid.getStringValueArray()[0]); > > Similarly, add the entry DN into the exception message in line 237. > > 10. In AuthSubsystem.java:461 you can iterate over hashtable values > directly, thus avoiding the lookup operation: > > for (AuthManagerProxy proxy : mAuthMgrInsts.values()) { > IAuthManager mgr = proxy.getAuthManager(); > ... > } > > 11. In PasswdUserDBAuthentication.java:188 the getUser() will return > null only if there's a problem. However, if you throw an exception in > line 190 it will be logged as "UID not found", which is not the case. I > think the null checking should be moved after the try-catch block like this: > > try { > user = ug.getUser(uid); > } catch (...) { > ... > } > > if (user == null) { > throw new EInvalidCredentials( > CMS.getUserMessage("CMS_AUTHENTICATION_INTERNAL_ERROR", > "Failure in User Group subsystem.")); > } > > Ideally the getUser() should throw an exception instead of returning > null. That would be fixed under ticket #201. > > 12. There's a formatting issue in DBSubsystem.java:411. Also, it would > be better to include which entry that has a problem: > > throw new Exception( > "Missing attribute " + PROP_NEXT_RANGE + " in entry " + dn); > > 13. Formatting issue in KeyRepository.java:254. Also, include the serial > number in the exception message in line 272: > > throw new EBaseException( > "Failed to recover Key for Serial Number " + serialNo); > > 14. In ARequestQueue.java:591 the boolean initialization is not > necessary because it will be initialized with the return value of > serviceRequest(). Also remove the auto-generated TODO comment. > > 15. In AuthTokenTest.java:122 it might be better to use this message: > > throw new Exception("Unable to get key2 as Date"); > > 16. Formatting issue in AuthTokenTest.java:143. > > 17. In DRMTool.java:1645 the readLine() will only return null if the > password file is empty, which I suppose is not allowed. So I think it > should throw an exception instead of continuing with empty password. > > 18. Same issue in PKCS12Export.java:227,239 as in #17. > > 19. In KRAService.java:101 remove the auto-generated TODO message. > > 20. In RecoveryService.java:200 it might be better to throw > EKRAException with user message CMS_KRA_INVALID_KEYRECORD. This may make > some other changes unnecessary. > > 21. As explained in #2, in HTTPClient.java:431,448 you can throw the > original exception object. > > 22. Also like in #2, in HTTPClient.java:1198 you could leave the > exception uncaught or throw the original exception object, but remove > the auto-generated TODO message in line 1201. > > 23. In ChallengeException.java:36,45, the original code would have > thrown an exception. The new code will continue and return an empty > string. It might be better to return the attribute directly and let the > caller handle the null value: > > public StateAttribute getState() { > return _res.getAttributeSet().getAttributeByType( > Attribute.STATE); > } > > public ReplyMessageAttribute getReplyMessage() { > return _res.getAttributeSet().getAttributeByType( > Attribute.REPLY_MESSAGE); > } > > 24. Same thing as #23 in RejectException.java:36. > > 25. In DerInputBuffer.java:58 and DerInputStream.java:117 to be > consistent the code should throw an IOException. > > 26. In IssuingDistributionPointExtension.java:199 add some exception > message, for example "Unable to get unaligned bit string." > > 27. Formatting issue in JSSUtil.java:71-72. Also, the exception message > probably should say "Cannot decode the given bytes." > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0011-2-Fixes-For-Review-Comments-For-NR2.patch Type: text/x-patch Size: 28761 bytes Desc: not available URL: From akoneru at redhat.com Tue Jun 12 21:53:23 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 12 Jun 2012 17:53:23 -0400 Subject: [Pki-devel] [PATCH 11-2] -- Re: [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review In-Reply-To: <4FD65959.6040201@redhat.com> References: <1339192391.25195.2.camel@abhishek> <4FD65959.6040201@redhat.com> Message-ID: <1339538003.31006.1.camel@abhishek> Submitting the PATCH 11-2 with fixes for review comments given. Build passed the smoke test. Thank you. Regards, Abhishek Koneru On Mon, 2012-06-11 at 15:47 -0500, Endi Sukma Dewata wrote: > On 6/8/2012 4:53 PM, Abhishek Koneru wrote: > > Please find attached [PATCH 11] with fixes for Coverity issues of > > category NULL RETURNS for DogTag 10. > > Some issues: > > 1. The link to JSS jar file should have been > /usr/share/java/jss/jss4.jar. This link is created by scripts/dev_setup. > > 2. In AuthToken.java:303,341,343,390 the code catches the exception and > throws a new exception but with the same type and message. This is not > necessary and it will change the stack trace information (it will no > longer show where the original exception happens). It's better to simply > not catch the exception and let it be handled by the caller. > > There are cases where catch-and-throw make sense. If you want to do > something but still want to keep the original stack trace you can > re-throw the same exception object (not create a new one): > > } catch (Exception e) { > // do something > throw e; > } > > If you want to change the exception type/message you can throw a new > exception that wraps the old exception: > > } catch (OldException e) { > throw new NewException(e); > // or throw new NewException(e.getMessage()); > } > > Wrapping is possible if the NewException has a constructor that takes > the OldException. This is to allow chaining the stack trace. If such > constructor is not available at least try to include the original > exception message. > > 3. In CMCAuth.java:877 the exception should throw the > CMS_AUTHENTICATION_MANAGER_NOT_FOUND message from UserMessages. > > 4. Similar to #2, in CMCAuth.java:907 it's not necessary to catch and > throw a new exception with the same type/message. > > 5. While you're at it, in SubjAltNameExt.java:255, the /* of String */ > comment can be removed since we're using generics now. > > 6. In DisplayHtmlServlet.java:65 moving the authenticate() into the > try-catch block doesn't seem to be necessary. The authenticate() throws > an EBaseException with is already declared by the process(). The > try-catch block is intended to deal with template problem, which is not > the case with authenticate(). > > 7. There's a formatting issue in ChallengeRevocationServlet1.java:138. > > 8. In UpdateCRL.java:123 the authenticate() is moved into a try-catch > block which will swallow all exceptions. I think the null return value > should be checked before the try-catch block. > > 9. In LDAPSecurityDomainSessionTable.java:195 you can reuse the > LDAPAttribute object obtained for null checking. Also, it would be > better to indicate which entry is invalid in the exception message. > > LDAPAttribute sid = entry.getAttribute("cn"); > if (sid == null) { > throw new Exception("Invalid LDAP Entry " + entry.getDN() > + ". No session id (cn)."); > } > ret.add(sid.getStringValueArray()[0]); > > Similarly, add the entry DN into the exception message in line 237. > > 10. In AuthSubsystem.java:461 you can iterate over hashtable values > directly, thus avoiding the lookup operation: > > for (AuthManagerProxy proxy : mAuthMgrInsts.values()) { > IAuthManager mgr = proxy.getAuthManager(); > ... > } > > 11. In PasswdUserDBAuthentication.java:188 the getUser() will return > null only if there's a problem. However, if you throw an exception in > line 190 it will be logged as "UID not found", which is not the case. I > think the null checking should be moved after the try-catch block like this: > > try { > user = ug.getUser(uid); > } catch (...) { > ... > } > > if (user == null) { > throw new EInvalidCredentials( > CMS.getUserMessage("CMS_AUTHENTICATION_INTERNAL_ERROR", > "Failure in User Group subsystem.")); > } > > Ideally the getUser() should throw an exception instead of returning > null. That would be fixed under ticket #201. > > 12. There's a formatting issue in DBSubsystem.java:411. Also, it would > be better to include which entry that has a problem: > > throw new Exception( > "Missing attribute " + PROP_NEXT_RANGE + " in entry " + dn); > > 13. Formatting issue in KeyRepository.java:254. Also, include the serial > number in the exception message in line 272: > > throw new EBaseException( > "Failed to recover Key for Serial Number " + serialNo); > > 14. In ARequestQueue.java:591 the boolean initialization is not > necessary because it will be initialized with the return value of > serviceRequest(). Also remove the auto-generated TODO comment. > > 15. In AuthTokenTest.java:122 it might be better to use this message: > > throw new Exception("Unable to get key2 as Date"); > > 16. Formatting issue in AuthTokenTest.java:143. > > 17. In DRMTool.java:1645 the readLine() will only return null if the > password file is empty, which I suppose is not allowed. So I think it > should throw an exception instead of continuing with empty password. > > 18. Same issue in PKCS12Export.java:227,239 as in #17. > > 19. In KRAService.java:101 remove the auto-generated TODO message. > > 20. In RecoveryService.java:200 it might be better to throw > EKRAException with user message CMS_KRA_INVALID_KEYRECORD. This may make > some other changes unnecessary. > > 21. As explained in #2, in HTTPClient.java:431,448 you can throw the > original exception object. > > 22. Also like in #2, in HTTPClient.java:1198 you could leave the > exception uncaught or throw the original exception object, but remove > the auto-generated TODO message in line 1201. > > 23. In ChallengeException.java:36,45, the original code would have > thrown an exception. The new code will continue and return an empty > string. It might be better to return the attribute directly and let the > caller handle the null value: > > public StateAttribute getState() { > return _res.getAttributeSet().getAttributeByType( > Attribute.STATE); > } > > public ReplyMessageAttribute getReplyMessage() { > return _res.getAttributeSet().getAttributeByType( > Attribute.REPLY_MESSAGE); > } > > 24. Same thing as #23 in RejectException.java:36. > > 25. In DerInputBuffer.java:58 and DerInputStream.java:117 to be > consistent the code should throw an IOException. > > 26. In IssuingDistributionPointExtension.java:199 add some exception > message, for example "Unable to get unaligned bit string." > > 27. Formatting issue in JSSUtil.java:71-72. Also, the exception message > probably should say "Cannot decode the given bytes." > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0011-2-Fixes-For-Review-Comments-For-NR2.patch Type: text/x-patch Size: 28761 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 13 04:15:44 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 12 Jun 2012 23:15:44 -0500 Subject: [Pki-devel] [PATCH 11-2] -- Re: [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review In-Reply-To: <1339538003.31006.1.camel@abhishek> References: <1339192391.25195.2.camel@abhishek> <4FD65959.6040201@redhat.com> <1339538003.31006.1.camel@abhishek> Message-ID: <4FD813F0.7040301@redhat.com> On 6/12/2012 4:53 PM, Abhishek Koneru wrote: > Submitting the PATCH 11-2 with fixes for review comments given. > Build passed the smoke test. >> 1. The link to JSS jar file should have been >> /usr/share/java/jss/jss4.jar. This link is created by scripts/dev_setup. The .classpath is not fixed yet. >> 12. There's a formatting issue in DBSubsystem.java:411. Also, it would >> be better to include which entry that has a problem: >> >> throw new Exception( >> "Missing attribute " + PROP_NEXT_RANGE + " in entry " + dn); The new code shows the constant name (PROP_NEXT_RANGE) instead of the actual attribute name (nextRange): throw new Exception( "Missing Attribute PROP_NEXT_RANGE in Entry" + dn); >> 20. In RecoveryService.java:200 it might be better to throw >> EKRAException with user message CMS_KRA_INVALID_KEYRECORD. This may make >> some other changes unnecessary. The new code gets the message from LogMessages instead of UserMessages: throw new EKRAException( CMS.getLogMessage("CMS_KRA_INVALID_KEYRECORD")); Some more issues: 28. In IAuthToken.java:218 the @return tag should be fixed, the method no longer returns null on error. 29. In IService.java:47 the new @throws tag is no longer needed. 30. Formatting issue in CMCAuth.java:907. 31. In ChallengeRevocationServlet1.java:135 the @throws tag doesn't match the exception. 32. In AuthTokenTest.java:144 include an exception message, for example: Unable to get key as String array. 33. In RecoveryService.java:132 the new @throws tag is no longer needed. 34. In CMSLDAP.java:212 it should throw the original exception object. 35. In HTTPClient.java:424 the inner try-catch block is actually not needed anymore. The finally-clause (lines 432-441) can be moved to the outer try-catch block at line 447. The null assignments (lines 438-440) are not necessary because these objects will be garbage collected anyway. Usually objects that require closing are handled like this: // declare variables and initialize with null Socket socket = null; OutputStream rawos = null; BufferedOutputStream os = null; PrintStream ps = null; try { // create objects socket = new Socket(hostname, port); rawos = socket.getOutputStream(); os = new BufferedOutputStream(rawos); ps = new PrintStream(os); ... } catch (Exception e) { ... throw e; } finally { // close in reverse order and ignore any errors if (ps != null) try { ps.close(); } catch (Exception e) { e.printStackTrace(); } if (rawos != null) try { rawos.close(); } catch (Exception e) { e.printStackTrace(); } if (os != null) try { os.close(); } catch (Exception e) { e.printStackTrace(); } if (socket != null) try { socket.close(); } catch (Exception e) { e.printStackTrace(); } } You probably can just close the outermost stream (the one created last, i.e. ps), it should automatically close the other streams and the socket too. 36. Formatting issue in HTTPClient.java:1196. 37. In DerInputStream.java:115 the @throws tag doesn't match the exception. -- Endi S. Dewata From akoneru at redhat.com Wed Jun 13 16:04:22 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 13 Jun 2012 12:04:22 -0400 Subject: [Pki-devel] [PATCH 11-3] -- Re: [PATCH 11-2] -- Re: [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review In-Reply-To: <4FD813F0.7040301@redhat.com> References: <1339192391.25195.2.camel@abhishek> <4FD65959.6040201@redhat.com> <1339538003.31006.1.camel@abhishek> <4FD813F0.7040301@redhat.com> Message-ID: <1339603462.31884.2.camel@abhishek> Please find attached PATCH 11-3 for review and commit. All the fixes for review comments included. --Abhishek Koneru On Tue, 2012-06-12 at 23:15 -0500, Endi Sukma Dewata wrote: > On 6/12/2012 4:53 PM, Abhishek Koneru wrote: > > Submitting the PATCH 11-2 with fixes for review comments given. > > Build passed the smoke test. > > >> 1. The link to JSS jar file should have been > >> /usr/share/java/jss/jss4.jar. This link is created by scripts/dev_setup. > > The .classpath is not fixed yet. > > >> 12. There's a formatting issue in DBSubsystem.java:411. Also, it would > >> be better to include which entry that has a problem: > >> > >> throw new Exception( > >> "Missing attribute " + PROP_NEXT_RANGE + " in entry " + dn); > > The new code shows the constant name (PROP_NEXT_RANGE) instead of the > actual attribute name (nextRange): > > throw new Exception( > "Missing Attribute PROP_NEXT_RANGE in Entry" + dn); > > >> 20. In RecoveryService.java:200 it might be better to throw > >> EKRAException with user message CMS_KRA_INVALID_KEYRECORD. This may make > >> some other changes unnecessary. > > The new code gets the message from LogMessages instead of UserMessages: > > throw new EKRAException( > CMS.getLogMessage("CMS_KRA_INVALID_KEYRECORD")); > > > Some more issues: > > 28. In IAuthToken.java:218 the @return tag should be fixed, the method > no longer returns null on error. > > 29. In IService.java:47 the new @throws tag is no longer needed. > > 30. Formatting issue in CMCAuth.java:907. > > 31. In ChallengeRevocationServlet1.java:135 the @throws tag doesn't > match the exception. > > 32. In AuthTokenTest.java:144 include an exception message, for example: > Unable to get key as String array. > > 33. In RecoveryService.java:132 the new @throws tag is no longer needed. > > 34. In CMSLDAP.java:212 it should throw the original exception object. > > 35. In HTTPClient.java:424 the inner try-catch block is actually not > needed anymore. The finally-clause (lines 432-441) can be moved to the > outer try-catch block at line 447. The null assignments (lines 438-440) > are not necessary because these objects will be garbage collected > anyway. Usually objects that require closing are handled like this: > > // declare variables and initialize with null > Socket socket = null; > OutputStream rawos = null; > BufferedOutputStream os = null; > PrintStream ps = null; > > try { > // create objects > socket = new Socket(hostname, port); > rawos = socket.getOutputStream(); > os = new BufferedOutputStream(rawos); > ps = new PrintStream(os); > ... > > } catch (Exception e) { > ... > throw e; > > } finally { > // close in reverse order and ignore any errors > if (ps != null) > try { ps.close(); } > catch (Exception e) { e.printStackTrace(); } > if (rawos != null) > try { rawos.close(); } > catch (Exception e) { e.printStackTrace(); } > if (os != null) > try { os.close(); } > catch (Exception e) { e.printStackTrace(); } > if (socket != null) > try { socket.close(); } > catch (Exception e) { e.printStackTrace(); } > } > > You probably can just close the outermost stream (the one created last, > i.e. ps), it should automatically close the other streams and the socket > too. > > 36. Formatting issue in HTTPClient.java:1196. > > 37. In DerInputStream.java:115 the @throws tag doesn't match the exception. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0011-3-Fixes-for-Review-Comments.patch Type: text/x-patch Size: 12489 bytes Desc: not available URL: From akoneru at redhat.com Wed Jun 13 21:31:38 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 13 Jun 2012 17:31:38 -0400 Subject: [Pki-devel] [PATCH] 0012 - Fixes for Coverity Issues of type StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for DogTag 10 Message-ID: <1339623098.11643.3.camel@abhishek> Please find attached PATCH 12 - with fixes for issues in Coverity of types StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for review. Build passed the Smoke Test. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0012-Fixes-for-Coverity-issues-of-type-Stringbuffer-NO_EQ.patch Type: text/x-patch Size: 33009 bytes Desc: not available URL: From rstclair at redhat.com Wed Jun 13 22:02:54 2012 From: rstclair at redhat.com (Bob St. Clair) Date: Wed, 13 Jun 2012 18:02:54 -0400 Subject: [Pki-devel] Dogtag Message-ID: <4FD90E0E.9050405@redhat.com> All, Is this internal only? I have a customer that wants to use smart cards in their own linux environment. They will need to issue their own certs on their smart cards. Since certificate system has certain requirements... Can a customer use Fedora dogtag in a RHEL 6.2 IDM environment? It would not be supported, but would it work? Thanks, Bob -- ************************** * rstclair at redhat.com * Mobile (919)741-3070 * Support (888)467-3342 ************************** From mharmsen at redhat.com Thu Jun 14 00:20:36 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 13 Jun 2012 17:20:36 -0700 Subject: [Pki-devel] Dogtag In-Reply-To: <4FD90E0E.9050405@redhat.com> References: <4FD90E0E.9050405@redhat.com> Message-ID: <4FD92E54.2020203@redhat.com> On 06/13/12 15:02, Bob St. Clair wrote: > All, > > Is this internal only? > No - pki-devel is a public mailing list > I have a customer that wants to use smart cards in their own linux > environment. They will need to issue their own certs on their smart > cards. > > Since certificate system has certain requirements... Can a customer > use Fedora dogtag in a RHEL 6.2 IDM environment? It would not be > supported, but would it work? > A non-GUI set of Dogtag 9 "pki-core" packages (including "pki-ca") are part of the RHEL 6 release as used by IPA, but they are not intended to be used as a stand-alone certificate system. We don't presently supply EPEL packages for the Dogtag GUI nor any of the other PKI subsystems for RHEL 6, nor are we likely to for the foreseeable future. A customer would simply need to install any additional packages and see if they work; they would need to replace the "ipa-theme" non-GUI packages with "dogtag-theme" GUI packages, and add the Fedora versions of "pki-kra", "pki-ocsp", "pki-tks", "pki-console", "pki-ra", and/or "pki-tps" packages as needed to support the other PKI subsystems. There might be an issue if the customer attempted to use some of the Fedora "pki-core" packages such as "pki-selinux" as these may be based upon a version of SELinux that is newer in Fedora. Less likely, although possible, the "pki-tps" compiled for certain versions of Fedora could be non-compatible with the RHEL 6 platform. I do not know if replacement of the non-GUI packages with GUI packages would disable the customer's ability to utilize IPA on their RHEL 6 installation (I would not think so, but I have never tried it). -- Matt > Thanks, > Bob > From edewata at redhat.com Thu Jun 14 22:16:04 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 Jun 2012 17:16:04 -0500 Subject: [Pki-devel] [PATCH 11-3] -- Re: [PATCH 11-2] -- Re: [PATCH 11] Dogtag 10 - Fixes for Coverity issues relating to NULL_RETURNS Category -- for review In-Reply-To: <1339603462.31884.2.camel@abhishek> References: <1339192391.25195.2.camel@abhishek> <4FD65959.6040201@redhat.com> <1339538003.31006.1.camel@abhishek> <4FD813F0.7040301@redhat.com> <1339603462.31884.2.camel@abhishek> Message-ID: <4FDA62A4.60009@redhat.com> On 6/13/2012 11:04 AM, Abhishek Koneru wrote: > Please find attached PATCH 11-3 for review and commit. > All the fixes for review comments included. ACK. Merged & pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Jun 15 00:11:50 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 Jun 2012 19:11:50 -0500 Subject: [Pki-devel] [PATCH] 0012 - Fixes for Coverity Issues of type StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for DogTag 10 In-Reply-To: <1339623098.11643.3.camel@abhishek> References: <1339623098.11643.3.camel@abhishek> Message-ID: <4FDA7DC6.2090505@redhat.com> On 6/13/2012 4:31 PM, Abhishek Koneru wrote: > Please find attached PATCH 12 - with fixes for issues in Coverity of > types StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , > Reverse_INull for review. Some issues: 1. There's a formatting issue in CMSCRLExtensions.java:586. 2. In CRLIssuingPoint.java:2712-2737 the String concatenations are replaced with StringBuffer. This is fine and not a big deal but it can be done more efficiently. See http://kaioa.com/node/59 and http://javarevisited.blogspot.com/2011/07/string-vs-stringbuffer-vs-stringbuilder.html. In this code the only thread using the StringBuffer is the current thread itself, so there's no concurrency issue. So the StringBuffer can be replaced with StringBuilder. Every time you do a "+" operation on Strings, the JVM will create a StringBuilder, append the Strings, then generate a new String that contains the concatenated text. So instead of this: splitTimes.append( "," + Long.toString(deltaTime) + "," + Long.toString(crlTime) + "," + Long.toString(totalTime) + ")"); you can reuse the same StringBuilder object like this: splitTimes.append(",").append(deltaTime).append(",").append(crlTime) .append(",").append(totalTime).append(")"); Notice the Long.toString() is not necessary because there are separate append() methods for each primitive type. Also with autoboxing the primitive types will be converted automatically to objects, so the code in lines 2722, 2729-2738 can be simplified like this: splitTimes.append(mSplits[i]); new Object[] { getId(), getCRLNumber(), getLastUpdate(), getNextUpdate(), mCRLSize, totalTime, crlTime, "" + deltaTime + splitTimes } 3. In CRLIssuingPoint.java:3098-3105,3151 whenever you remove the { } surrounding a code block you should fix the indentation. 4. In NameValuePairs.java:47 you can use StringBuilder too. In line 51 it's better to use separate append() for each String component. 5. In SimpleProperties.java you should use Eclipse to generate hashCode() too, it goes together with equals(). 6. In Auditor.java the StringBuilder can be created once at line 99, then the subsequent code will append each String component separately. 7. In ACL.java:153 you can use StringBuilder. In lines 159 and 163 it's not necessary to call toString() explicitly. 8. In ExtDataHashtable.java:59 I think you can actually remove the putAll() because it's identical to the one in the super class. 9. In RequestTest.java you should add hashCode() as well. 10. Same thing in CMCResponse.java:125-130, use StringBuilder, separate appends, no explicit toString(). 11. Same thing in PrettyPrintCert.java:89,200,221, use StringBuilder, separate appends, no explicit toString(). 12. Add hashCode() to the following files: - CMSProperties.java - PKCS10Attributes.java - DSAPrivateKey.java - DSAPublicKey.java - RSAPublicKey.java - AlgIdDSA.java - CRLExtensions.java - CertificateExtensions.java - Extensions.java -- Endi S. Dewata From alee at redhat.com Fri Jun 15 00:36:45 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 14 Jun 2012 20:36:45 -0400 Subject: [Pki-devel] [PATCH] 0012 - Fixes for Coverity Issues of type StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for DogTag 10 In-Reply-To: <4FDA7DC6.2090505@redhat.com> References: <1339623098.11643.3.camel@abhishek> <4FDA7DC6.2090505@redhat.com> Message-ID: <1339720606.3069.94.camel@aleeredhat.laptop> On Thu, 2012-06-14 at 19:11 -0500, Endi Sukma Dewata wrote: > On 6/13/2012 4:31 PM, Abhishek Koneru wrote: > > Please find attached PATCH 12 - with fixes for issues in Coverity of > > types StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , > > Reverse_INull for review. > > Some issues: > > 1. There's a formatting issue in CMSCRLExtensions.java:586. > > 2. In CRLIssuingPoint.java:2712-2737 the String concatenations are > replaced with StringBuffer. This is fine and not a big deal but it can > be done more efficiently. See http://kaioa.com/node/59 and > http://javarevisited.blogspot.com/2011/07/string-vs-stringbuffer-vs-stringbuilder.html. > > In this code the only thread using the StringBuffer is the current > thread itself, so there's no concurrency issue. So the StringBuffer can > be replaced with StringBuilder. > > Every time you do a "+" operation on Strings, the JVM will create a > StringBuilder, append the Strings, then generate a new String that > contains the concatenated text. So instead of this: > > splitTimes.append( > "," + Long.toString(deltaTime) + "," + Long.toString(crlTime) > + "," + Long.toString(totalTime) + ")"); > > you can reuse the same StringBuilder object like this: > > splitTimes.append(",").append(deltaTime).append(",").append(crlTime) > .append(",").append(totalTime).append(")"); > While I appreciate that the above formulation is more efficient, there is a drawback in terms of readability. This following formulation may be a little less efficient but is much more readable: splitTimes.append("," + deltaTime + "," + crlTime + "," + totalTime + ")"); I suggest that we not sacrifice readability for efficiency until we have profiling data in hand. I suspect that this little inefficiency will be the very least of our performance issues. > Notice the Long.toString() is not necessary because there are separate > append() methods for each primitive type. Also with autoboxing the > primitive types will be converted automatically to objects, so the code > in lines 2722, 2729-2738 can be simplified like this: > > splitTimes.append(mSplits[i]); > > new Object[] { > getId(), > getCRLNumber(), > getLastUpdate(), > getNextUpdate(), > mCRLSize, > totalTime, > crlTime, > "" + deltaTime + splitTimes > } > > 3. In CRLIssuingPoint.java:3098-3105,3151 whenever you remove the { } > surrounding a code block you should fix the indentation. > > 4. In NameValuePairs.java:47 you can use StringBuilder too. In line 51 > it's better to use separate append() for each String component. > > 5. In SimpleProperties.java you should use Eclipse to generate > hashCode() too, it goes together with equals(). > > 6. In Auditor.java the StringBuilder can be created once at line 99, > then the subsequent code will append each String component separately. > > 7. In ACL.java:153 you can use StringBuilder. In lines 159 and 163 it's > not necessary to call toString() explicitly. > > 8. In ExtDataHashtable.java:59 I think you can actually remove the > putAll() because it's identical to the one in the super class. > > 9. In RequestTest.java you should add hashCode() as well. > > 10. Same thing in CMCResponse.java:125-130, use StringBuilder, separate > appends, no explicit toString(). > > 11. Same thing in PrettyPrintCert.java:89,200,221, use StringBuilder, > separate appends, no explicit toString(). > > 12. Add hashCode() to the following files: > - CMSProperties.java > - PKCS10Attributes.java > - DSAPrivateKey.java > - DSAPublicKey.java > - RSAPublicKey.java > - AlgIdDSA.java > - CRLExtensions.java > - CertificateExtensions.java > - Extensions.java > From edewata at redhat.com Fri Jun 15 02:02:03 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 14 Jun 2012 21:02:03 -0500 Subject: [Pki-devel] [PATCH] 0012 - Fixes for Coverity Issues of type StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for DogTag 10 In-Reply-To: <1339720606.3069.94.camel@aleeredhat.laptop> References: <1339623098.11643.3.camel@abhishek> <4FDA7DC6.2090505@redhat.com> <1339720606.3069.94.camel@aleeredhat.laptop> Message-ID: <4FDA979B.4020409@redhat.com> On 6/14/2012 7:36 PM, Ade Lee wrote: >> Every time you do a "+" operation on Strings, the JVM will create a >> StringBuilder, append the Strings, then generate a new String that >> contains the concatenated text. So instead of this: >> >> splitTimes.append( >> "," + Long.toString(deltaTime) + "," + Long.toString(crlTime) >> + "," + Long.toString(totalTime) + ")"); >> >> you can reuse the same StringBuilder object like this: >> >> splitTimes.append(",").append(deltaTime).append(",").append(crlTime) >> .append(",").append(totalTime).append(")"); >> > > While I appreciate that the above formulation is more efficient, there > is a drawback in terms of readability. This following formulation may > be a little less efficient but is much more readable: > > splitTimes.append("," + deltaTime + "," + crlTime + "," + totalTime + ")"); > > I suggest that we not sacrifice readability for efficiency until we have > profiling data in hand. I suspect that this little inefficiency will be > the very least of our performance issues. Agreed. For better readability we can use this: splitTimes.append( String.format(",%d,%d,%d)", deltaTime, crlTime, totalTime)); -- Endi S. Dewata From akoneru at redhat.com Fri Jun 15 17:56:04 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 15 Jun 2012 13:56:04 -0400 Subject: [Pki-devel] [PATCH] 12-2 Fixes for review comments for -- Re: [PATCH] 0012 - Fixes for Coverity Issues of type StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for DogTag 10 In-Reply-To: <4FDA7DC6.2090505@redhat.com> References: <1339623098.11643.3.camel@abhishek> <4FDA7DC6.2090505@redhat.com> Message-ID: <1339782964.25354.4.camel@abhishek> Please find attached the patch for fixes for the issues in PATCH 12 for review and commit. Regards, Abhishek Koneru On Thu, 2012-06-14 at 19:11 -0500, Endi Sukma Dewata wrote: > On 6/13/2012 4:31 PM, Abhishek Koneru wrote: > > Please find attached PATCH 12 - with fixes for issues in Coverity of > > types StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , > > Reverse_INull for review. > > Some issues: > > 1. There's a formatting issue in CMSCRLExtensions.java:586. > > 2. In CRLIssuingPoint.java:2712-2737 the String concatenations are > replaced with StringBuffer. This is fine and not a big deal but it can > be done more efficiently. See http://kaioa.com/node/59 and > http://javarevisited.blogspot.com/2011/07/string-vs-stringbuffer-vs-stringbuilder.html. > > In this code the only thread using the StringBuffer is the current > thread itself, so there's no concurrency issue. So the StringBuffer can > be replaced with StringBuilder. > > Every time you do a "+" operation on Strings, the JVM will create a > StringBuilder, append the Strings, then generate a new String that > contains the concatenated text. So instead of this: > > splitTimes.append( > "," + Long.toString(deltaTime) + "," + Long.toString(crlTime) > + "," + Long.toString(totalTime) + ")"); > > you can reuse the same StringBuilder object like this: > > splitTimes.append(",").append(deltaTime).append(",").append(crlTime) > .append(",").append(totalTime).append(")"); > > Notice the Long.toString() is not necessary because there are separate > append() methods for each primitive type. Also with autoboxing the > primitive types will be converted automatically to objects, so the code > in lines 2722, 2729-2738 can be simplified like this: > > splitTimes.append(mSplits[i]); > > new Object[] { > getId(), > getCRLNumber(), > getLastUpdate(), > getNextUpdate(), > mCRLSize, > totalTime, > crlTime, > "" + deltaTime + splitTimes > } > > 3. In CRLIssuingPoint.java:3098-3105,3151 whenever you remove the { } > surrounding a code block you should fix the indentation. > > 4. In NameValuePairs.java:47 you can use StringBuilder too. In line 51 > it's better to use separate append() for each String component. > > 5. In SimpleProperties.java you should use Eclipse to generate > hashCode() too, it goes together with equals(). > > 6. In Auditor.java the StringBuilder can be created once at line 99, > then the subsequent code will append each String component separately. > > 7. In ACL.java:153 you can use StringBuilder. In lines 159 and 163 it's > not necessary to call toString() explicitly. > > 8. In ExtDataHashtable.java:59 I think you can actually remove the > putAll() because it's identical to the one in the super class. > > 9. In RequestTest.java you should add hashCode() as well. > > 10. Same thing in CMCResponse.java:125-130, use StringBuilder, separate > appends, no explicit toString(). > > 11. Same thing in PrettyPrintCert.java:89,200,221, use StringBuilder, > separate appends, no explicit toString(). > > 12. Add hashCode() to the following files: > - CMSProperties.java > - PKCS10Attributes.java > - DSAPrivateKey.java > - DSAPublicKey.java > - RSAPublicKey.java > - AlgIdDSA.java > - CRLExtensions.java > - CertificateExtensions.java > - Extensions.java > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0012-2-Fixes-for-Review-Comments-for-PATCH-12.patch Type: text/x-patch Size: 29978 bytes Desc: not available URL: From akoneru at redhat.com Fri Jun 15 20:51:52 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 15 Jun 2012 16:51:52 -0400 Subject: [Pki-devel] [PATCH] 13 -- Fixes for Coverity Issues of type NULL_RETURNS for review Message-ID: <1339793512.2242.1.camel@abhishek> Please review the patch which has the fixes for Coverity issues of type NULL_RETURNS. Smoke Test passed. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0013-Fixes-for-Coverity-Issues-of-type-Null-Returns-Part-.patch Type: text/x-patch Size: 16318 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 15 22:46:14 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 15 Jun 2012 17:46:14 -0500 Subject: [Pki-devel] [PATCH] 12-2 Fixes for review comments for -- Re: [PATCH] 0012 - Fixes for Coverity Issues of type StringBuffer_Concatenation, Wrong_Map_Iterator, No_Equals_Method , Reverse_INull for DogTag 10 In-Reply-To: <1339782964.25354.4.camel@abhishek> References: <1339623098.11643.3.camel@abhishek> <4FDA7DC6.2090505@redhat.com> <1339782964.25354.4.camel@abhishek> Message-ID: <4FDBBB36.5030902@redhat.com> On 6/15/2012 12:56 PM, Abhishek Koneru wrote: > Please find attached the patch for fixes for the issues in PATCH 12 for > review and commit. ACK. Merged and pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Jun 18 18:01:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 Jun 2012 13:01:01 -0500 Subject: [Pki-devel] [PATCH] 68 Fixed null pointer exception in pkisilent on connection error. Message-ID: <4FDF6CDD.4090802@redhat.com> Previously HTTPClient.sslConnect() would return a null if there is a connection issue. Some code in pkisilent did not check the return value properly so it would throw an exception. The sslConnect() has been modified to throw an exception instead. Ticket #180 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0068-Fixed-null-pointer-exception-in-pkisilent-on-connect.patch Type: text/x-patch Size: 43250 bytes Desc: not available URL: From edewata at redhat.com Mon Jun 18 19:47:46 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 Jun 2012 14:47:46 -0500 Subject: [Pki-devel] [PATCH] 68 Fixed null pointer exception in pkisilent on connection error. In-Reply-To: <4FDF6CDD.4090802@redhat.com> References: <4FDF6CDD.4090802@redhat.com> Message-ID: <4FDF85E2.8090708@redhat.com> On 6/18/2012 1:01 PM, Endi Sukma Dewata wrote: > Previously HTTPClient.sslConnect() would return a null if there is > a connection issue. Some code in pkisilent did not check the return > value properly so it would throw an exception. The sslConnect() has > been modified to throw an exception instead. > > Ticket #180 Revised based on Abhishek's feedback: 1. Reformat the finally clause. 2. Removed try-catch for ps.close(). 3. Fixed missing js.close(). -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0068-1-Fixed-null-pointer-exception-in-pkisilent-on-connect.patch Type: text/x-patch Size: 44053 bytes Desc: not available URL: From akoneru at redhat.com Mon Jun 18 20:11:43 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 18 Jun 2012 16:11:43 -0400 Subject: [Pki-devel] [PATCH] 68 Fixed null pointer exception in pkisilent on connection error. In-Reply-To: <4FDF85E2.8090708@redhat.com> References: <4FDF6CDD.4090802@redhat.com> <4FDF85E2.8090708@redhat.com> Message-ID: <1340050303.29265.4.camel@abhishek> ACK. Endi please push to master. -Abhishek Koneru On Mon, 2012-06-18 at 14:47 -0500, Endi Sukma Dewata wrote: > On 6/18/2012 1:01 PM, Endi Sukma Dewata wrote: > > Previously HTTPClient.sslConnect() would return a null if there is > > a connection issue. Some code in pkisilent did not check the return > > value properly so it would throw an exception. The sslConnect() has > > been modified to throw an exception instead. > > > > Ticket #180 > > Revised based on Abhishek's feedback: > > 1. Reformat the finally clause. > 2. Removed try-catch for ps.close(). > 3. Fixed missing js.close(). > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon Jun 18 20:16:17 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 Jun 2012 15:16:17 -0500 Subject: [Pki-devel] [PATCH] 68 Fixed null pointer exception in pkisilent on connection error. In-Reply-To: <1340050303.29265.4.camel@abhishek> References: <4FDF6CDD.4090802@redhat.com> <4FDF85E2.8090708@redhat.com> <1340050303.29265.4.camel@abhishek> Message-ID: <4FDF8C91.50308@redhat.com> On 6/18/2012 3:11 PM, Abhishek Koneru wrote: > ACK. Endi please push to master. Pushed to master. Thanks! -- Endi S. Dewata From edewata at redhat.com Mon Jun 18 21:10:14 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 Jun 2012 16:10:14 -0500 Subject: [Pki-devel] [PATCH] 13 -- Fixes for Coverity Issues of type NULL_RETURNS for review In-Reply-To: <1339793512.2242.1.camel@abhishek> References: <1339793512.2242.1.camel@abhishek> Message-ID: <4FDF9936.9000908@redhat.com> On 6/15/2012 3:51 PM, Abhishek Koneru wrote: > Please review the patch which has the fixes for Coverity issues of type > NULL_RETURNS. Some comments: 1. In UGSubsystem.java:421 if uid is null it will throw an exception with this message: "No User with UID "+uid. Since the uid is null the message is not helpful for troubleshooting. It would be better to say something like "No Attribute UID in LDAP Entry "+entry.getDN(). 2. Same issue in UGSubsystem.java:480. 3. Formatting issue in UGSubsystem.java:1218. 4. In UGSubsystem.java:1647 the bitwise XOR operator is used on boolean values. This is fine but I'd rather not do it because it can be done with logical operator too. The extra parenthesis is not needed because of operator precedence. So the code may look like this: // if both are null return true if (rdn1 == null && rdn2 == null) { return true; } // if one of them is null return false if (rdn1 == null || rdn2 == null) { return false; } // at this point none of them is null 5. In RequestTest.java the checkReturnValue() might not be correct. If the retVal is null all instanceof checking will be false, so type will be empty string. Some of the tests already check the retVal using assertNotNull() which should throw an exception if it's null. Let's make sure the other tests do the same thing and see if Coverity still complains. 6. In RecoveryService.java:454,594 if the code couldn't find the certificate from the request it will throw CMS_KRA_INVALID_KEYRECORD. It might be better to throw CMS_KRA_PKCS12_FAILED_1 with additional parameter "Missing certificate". -- Endi S. Dewata From edewata at redhat.com Tue Jun 19 00:06:06 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 18 Jun 2012 19:06:06 -0500 Subject: [Pki-devel] [PATCH] 69 Fixed problem removing user certificate. Message-ID: <4FDFC26E.9010304@redhat.com> Generally the user LDAP entry does not contain a seeAlso attribute unless it's a special database user. The UGSubsystem.removeUserCert() would fail because it tried to remove the seeAlso attribute. Now the code has been fixed to remove the seeAlso using a separate modify operation and ignore the error if it fails due to missing attribute. Ticket #182 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0069-Fixed-problem-removing-user-certificate.patch Type: text/x-patch Size: 7109 bytes Desc: not available URL: From akoneru at redhat.com Tue Jun 19 15:53:23 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 19 Jun 2012 11:53:23 -0400 Subject: [Pki-devel] [PATCH] 13-1 Fixes for issues in -- [PATCH] 13 -- Fixes for Coverity Issues of type NULL_RETURNS for review In-Reply-To: <4FDF9936.9000908@redhat.com> References: <1339793512.2242.1.camel@abhishek> <4FDF9936.9000908@redhat.com> Message-ID: <1340121203.15099.2.camel@abhishek> Please find attached the patch with fixes for the review comments given for PATCH 13. Regards, Abhishek Koneru On Mon, 2012-06-18 at 16:10 -0500, Endi Sukma Dewata wrote: > On 6/15/2012 3:51 PM, Abhishek Koneru wrote: > > Please review the patch which has the fixes for Coverity issues of type > > NULL_RETURNS. > > Some comments: > > 1. In UGSubsystem.java:421 if uid is null it will throw an exception > with this message: "No User with UID "+uid. Since the uid is null the > message is not helpful for troubleshooting. It would be better to say > something like "No Attribute UID in LDAP Entry "+entry.getDN(). > > 2. Same issue in UGSubsystem.java:480. > > 3. Formatting issue in UGSubsystem.java:1218. > > 4. In UGSubsystem.java:1647 the bitwise XOR operator is used on boolean > values. This is fine but I'd rather not do it because it can be done > with logical operator too. The extra parenthesis is not needed because > of operator precedence. So the code may look like this: > > // if both are null return true > if (rdn1 == null && rdn2 == null) { > return true; > } > > // if one of them is null return false > if (rdn1 == null || rdn2 == null) { > return false; > } > > // at this point none of them is null > > 5. In RequestTest.java the checkReturnValue() might not be correct. If > the retVal is null all instanceof checking will be false, so type will > be empty string. Some of the tests already check the retVal using > assertNotNull() which should throw an exception if it's null. Let's make > sure the other tests do the same thing and see if Coverity still complains. > > 6. In RecoveryService.java:454,594 if the code couldn't find the > certificate from the request it will throw CMS_KRA_INVALID_KEYRECORD. It > might be better to throw CMS_KRA_PKCS12_FAILED_1 with additional > parameter "Missing certificate". > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0013-1-Fixes-for-Review-Comments-for-Patch-13.patch Type: text/x-patch Size: 8669 bytes Desc: not available URL: From akoneru at redhat.com Tue Jun 19 20:20:10 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 19 Jun 2012 16:20:10 -0400 Subject: [Pki-devel] [PATCH] 14 Fixes for Some Resource Leaks in DogTag 10 shown in Coverity Message-ID: <1340137210.15099.5.camel@abhishek> Please review the attached patch which has the fixes for Resource leak cases in Coverity, for DogTag 10. Build passed the smoke test. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0014-Fixes-for-Resource-Leaks-shown-in-Coverity-for-DogTa.patch Type: text/x-patch Size: 54458 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 20 14:34:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 20 Jun 2012 09:34:53 -0500 Subject: [Pki-devel] [PATCH] 13-1 Fixes for issues in -- [PATCH] 13 -- Fixes for Coverity Issues of type NULL_RETURNS for review In-Reply-To: <1340121203.15099.2.camel@abhishek> References: <1339793512.2242.1.camel@abhishek> <4FDF9936.9000908@redhat.com> <1340121203.15099.2.camel@abhishek> Message-ID: <4FE1DF8D.6060005@redhat.com> On 6/19/2012 10:53 AM, Abhishek Koneru wrote: > Please find attached the patch with fixes for the review comments given > for PATCH 13. ACK. Merged & pushed to master. -- Endi S. Dewata From akoneru at redhat.com Wed Jun 20 17:59:58 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 20 Jun 2012 13:59:58 -0400 Subject: [Pki-devel] [PATCH] 15 Fixes for Coverity Issues of type Resource_Leak in DogTag 10 - for review Message-ID: <1340215198.2544.2.camel@abhishek> Please find attached the patch with fixes for remaining issues w.r.t resource leaks as shown in Coverity for Dogtag 10. Build passed the smoke test. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0015-Fixes-for-Coverity-issues-of-type-Resource-Leaks-Rem.patch Type: text/x-patch Size: 50393 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 20 23:30:09 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 20 Jun 2012 18:30:09 -0500 Subject: [Pki-devel] [PATCH] 14 Fixes for Some Resource Leaks in DogTag 10 shown in Coverity In-Reply-To: <1340137210.15099.5.camel@abhishek> References: <1340137210.15099.5.camel@abhishek> Message-ID: <4FE25D01.5080201@redhat.com> On 6/19/2012 3:20 PM, Abhishek Koneru wrote: > Please review the attached patch which has the fixes for Resource leak > cases in Coverity, for DogTag 10. Some comments: 1. In PKCS12Export.java:242 the in.close() should be moved into a finally block. It might not matter much because the program will exit on exception, but we should keep it consistent. 2. Unlike previous cases, in ConfigureCA.BackupPanel() the streams are used sequentially (not simultaneously), so I think the close() methods should be called at the original positions to make sure the data is flushed before it's read by the next stream. To avoid resource leaks you can use separate try-finally block for each stream: FileOutputStream fos = null; try { fos = new FileOutputStream(...); ... } finally { if (fos != null) fos.close(); } BufferedReader br = null; try { br = new BufferedReader(...); ... } finally { if (br != null) br.close(); } FileInputStream fis = null; try { fis = new FileInputStream(...); ... } finally { if (fis != null) fis.close(); } No need to catch the exception in the above try-finally blocks, you can use the catch block at line 942. 3. Same issue in ConfigureDRM.SavePKCS12Panel(). 4. Same issue in ConfigureOCSP.SavePKCS12Panel(). 5. Same issue in ConfigureTKS.SavePKCS12Panel(). 6. In Con2Agent.java:194 the flush() invocations should not be removed to make sure the request is sent before the response is read using stdin1. The flush() invocations in lines 203-204 can be removed because it's going to be closed anyway. 7. In ServerInfo.java:299 the close() invocation is no longer needed. 8. In TestClient.getProperties() the stream should be closed in a finally block in case the load() throws an exception. 9. In UserEnroll.java:305,313,321 remove the auto-generated comment. 10. Similar to #6, in HTTPClient.java:242 the flush() invocations should not be removed. 11. In HTTPClient.java:1013,1089 the null assignment is not necessary because the variable will be come out of scope as soon as it exits the method. -- Endi S. Dewata From akoneru at redhat.com Thu Jun 21 15:16:13 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 21 Jun 2012 11:16:13 -0400 Subject: [Pki-devel] [PATCH] 14-2 Fixes for review comments for -- [PATCH] 14 Fixes for Some Resource Leaks in DogTag 10 shown in Coverity In-Reply-To: <4FE25D01.5080201@redhat.com> References: <1340137210.15099.5.camel@abhishek> <4FE25D01.5080201@redhat.com> Message-ID: <1340291773.3860.2.camel@abhishek.mynetwork.com> Please find attached the patch with fixes for review comments for Patch 14 for review. Regards, Abhishek Koneru On Wed, 2012-06-20 at 18:30 -0500, Endi Sukma Dewata wrote: > On 6/19/2012 3:20 PM, Abhishek Koneru wrote: > > Please review the attached patch which has the fixes for Resource leak > > cases in Coverity, for DogTag 10. > > Some comments: > > 1. In PKCS12Export.java:242 the in.close() should be moved into a > finally block. It might not matter much because the program will exit on > exception, but we should keep it consistent. > > 2. Unlike previous cases, in ConfigureCA.BackupPanel() the streams are > used sequentially (not simultaneously), so I think the close() methods > should be called at the original positions to make sure the data is > flushed before it's read by the next stream. To avoid resource leaks you > can use separate try-finally block for each stream: > > FileOutputStream fos = null; > try { > fos = new FileOutputStream(...); > ... > } finally { > if (fos != null) fos.close(); > } > > BufferedReader br = null; > try { > br = new BufferedReader(...); > ... > } finally { > if (br != null) br.close(); > } > > FileInputStream fis = null; > try { > fis = new FileInputStream(...); > ... > } finally { > if (fis != null) fis.close(); > } > > No need to catch the exception in the above try-finally blocks, you can > use the catch block at line 942. > > 3. Same issue in ConfigureDRM.SavePKCS12Panel(). > > 4. Same issue in ConfigureOCSP.SavePKCS12Panel(). > > 5. Same issue in ConfigureTKS.SavePKCS12Panel(). > > 6. In Con2Agent.java:194 the flush() invocations should not be removed > to make sure the request is sent before the response is read using > stdin1. The flush() invocations in lines 203-204 can be removed because > it's going to be closed anyway. > > 7. In ServerInfo.java:299 the close() invocation is no longer needed. > > 8. In TestClient.getProperties() the stream should be closed in a > finally block in case the load() throws an exception. > > 9. In UserEnroll.java:305,313,321 remove the auto-generated comment. > > 10. Similar to #6, in HTTPClient.java:242 the flush() invocations should > not be removed. > > 11. In HTTPClient.java:1013,1089 the null assignment is not necessary > because the variable will be come out of scope as soon as it exits the > method. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0014-2-Fixes-for-review-comments-given-for-Patch-14.patch Type: text/x-patch Size: 22258 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 21 16:35:35 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Jun 2012 11:35:35 -0500 Subject: [Pki-devel] [PATCH] 70 Fixed equals() and hashCode() in X500Name and RDN. Message-ID: <4FE34D57.8040903@redhat.com> The X500Name and RDN have been modified to fix the incorrect method signature for equals() and the missing hashCode(). Ticket #206 ACKed by Christina last week. Pushed to master. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0070-Fixed-equals-and-hashCode-in-X500Name-and-RDN.patch Type: text/x-patch Size: 3825 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 21 20:23:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Jun 2012 15:23:57 -0500 Subject: [Pki-devel] [PATCH] 14-2 Fixes for review comments for -- [PATCH] 14 Fixes for Some Resource Leaks in DogTag 10 shown in Coverity In-Reply-To: <1340291773.3860.2.camel@abhishek.mynetwork.com> References: <1340137210.15099.5.camel@abhishek> <4FE25D01.5080201@redhat.com> <1340291773.3860.2.camel@abhishek.mynetwork.com> Message-ID: <4FE382DD.9040003@redhat.com> On 6/21/2012 10:16 AM, Abhishek Koneru wrote: > Please find attached the patch with fixes for review comments for Patch > 14 for review. ACK. Merged & pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 21 23:43:19 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 21 Jun 2012 18:43:19 -0500 Subject: [Pki-devel] [PATCH] 15 Fixes for Coverity Issues of type Resource_Leak in DogTag 10 - for review In-Reply-To: <1340215198.2544.2.camel@abhishek> References: <1340215198.2544.2.camel@abhishek> Message-ID: <4FE3B197.1090208@redhat.com> On 6/20/2012 12:59 PM, Abhishek Koneru wrote: > Please find attached the patch with fixes for remaining issues w.r.t > resource leaks as shown in Coverity for Dogtag 10. Some comments: 1. In CertificateAuthority.java:1336 the code should check for null value in case the FileInputStream constructor fails. 2. Same thing in PWsdrCache.java:337,439. 3. In HttpClient.java:95 the in.close() should be done in a finally block in case the in.read() fails. 4. Formatting issue in HttpClient.java:109-237. 5. In HttpClient.java:166,180 the socket shouldn't be closed there because the "is" and "dos" streams are still using the socket. I think it should be closed in the finally block in line 240. 6. Like in the previous patch, in OCSPClient.java:259 the close() should be called in a finally block. 7. Same thing in PasswordCache.java:198. 8. In StorageKeyUnit.java:280 the patch should check for null "fi" in case an error happens before it's initialized. 9. Formatting issue in Utils.java:171,179. Also remove the auto-generated comment in line 175. 10. In Utils.java:168 the original code catches and swallows the exception. Ideally the exception should be handled by the caller. It looks like the copy() method isn't actually used, so you can modify the catch block to re-throw the exception, and the close() should be done in a finally block. 11. In PresenceServerExtension.java:314 the close() is no longer necessary. 12. To be consistent we should close the streams in a finally block in the following code: - PresenceServerExtension.java:326 - CRLDistributionPoint.java:341 - CRLDistributionPointsExtension.java:297 - FreshestCRLExtension.java:302 - IssuingDistributionPoint.java:313 - IssuingDistributionPointExtension.java:419 -- Endi S. Dewata From akoneru at redhat.com Fri Jun 22 16:12:07 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 22 Jun 2012 12:12:07 -0400 Subject: [Pki-devel] [PATCH] 15 -2 Fixes for review comments on -- [PATCH] 15 Fixes for Coverity Issues of type Resource_Leak in DogTag 10 - for review In-Reply-To: <4FE3B197.1090208@redhat.com> References: <1340215198.2544.2.camel@abhishek> <4FE3B197.1090208@redhat.com> Message-ID: <1340381527.11863.2.camel@abhishek> Please find attached the patch with fixes for review comments given for PATCH 15 for review. Regards, Abhishek Koneru On Thu, 2012-06-21 at 18:43 -0500, Endi Sukma Dewata wrote: > On 6/20/2012 12:59 PM, Abhishek Koneru wrote: > > Please find attached the patch with fixes for remaining issues w.r.t > > resource leaks as shown in Coverity for Dogtag 10. > > Some comments: > > 1. In CertificateAuthority.java:1336 the code should check for null > value in case the FileInputStream constructor fails. > > 2. Same thing in PWsdrCache.java:337,439. > > 3. In HttpClient.java:95 the in.close() should be done in a finally > block in case the in.read() fails. > > 4. Formatting issue in HttpClient.java:109-237. > > 5. In HttpClient.java:166,180 the socket shouldn't be closed there > because the "is" and "dos" streams are still using the socket. I think > it should be closed in the finally block in line 240. > > 6. Like in the previous patch, in OCSPClient.java:259 the close() should > be called in a finally block. > > 7. Same thing in PasswordCache.java:198. > > 8. In StorageKeyUnit.java:280 the patch should check for null "fi" in > case an error happens before it's initialized. > > 9. Formatting issue in Utils.java:171,179. Also remove the > auto-generated comment in line 175. > > 10. In Utils.java:168 the original code catches and swallows the > exception. Ideally the exception should be handled by the caller. It > looks like the copy() method isn't actually used, so you can modify the > catch block to re-throw the exception, and the close() should be done in > a finally block. > > 11. In PresenceServerExtension.java:314 the close() is no longer necessary. > > 12. To be consistent we should close the streams in a finally block in > the following code: > - PresenceServerExtension.java:326 > - CRLDistributionPoint.java:341 > - CRLDistributionPointsExtension.java:297 > - FreshestCRLExtension.java:302 > - IssuingDistributionPoint.java:313 > - IssuingDistributionPointExtension.java:419 > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0015-2-Fixes-for-Endi-s-Review-for-patch-15.patch Type: text/x-patch Size: 26885 bytes Desc: not available URL: From edewata at redhat.com Mon Jun 25 16:26:13 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 25 Jun 2012 11:26:13 -0500 Subject: [Pki-devel] [PATCH] 15 -2 Fixes for review comments on -- [PATCH] 15 Fixes for Coverity Issues of type Resource_Leak in DogTag 10 - for review In-Reply-To: <1340381527.11863.2.camel@abhishek> References: <1340215198.2544.2.camel@abhishek> <4FE3B197.1090208@redhat.com> <1340381527.11863.2.camel@abhishek> Message-ID: <4FE89125.8020603@redhat.com> On 6/22/2012 11:12 AM, Abhishek Koneru wrote: > Please find attached the patch with fixes for review comments given for > PATCH 15 for review. A few more issues: 13. In PasswordCache.java:204 the "r" should be checked for null because the FileReader() constructor could fail. 14. In HttpClient.java:173-180 there's a new try-catch block that swallows the exception, changing the original behavior. The original code would let the caller handle the exception. This code was added in the first patch but only partially reverted in the second patch. It's always good to compare the cumulative patch against the original code (e.g. git diff ). The try-catch block in line 121-170 doesn't seem to be correct either. I think it should let the exception be handled by the caller. Feel free to fix this too, or just leave it as is because this is outside the scope of this patch. -- Endi S. Dewata From akoneru at redhat.com Mon Jun 25 18:03:41 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 25 Jun 2012 14:03:41 -0400 Subject: [Pki-devel] [PATCH] 15-3 Fixes for review comments on -- [PATCH] 15 -2 Fixes for review comments for Patch 15 In-Reply-To: <4FE89125.8020603@redhat.com> References: <1340215198.2544.2.camel@abhishek> <4FE3B197.1090208@redhat.com> <1340381527.11863.2.camel@abhishek> <4FE89125.8020603@redhat.com> Message-ID: <1340647421.16869.3.camel@abhishek> Please find attached the patch with fixes for review comments given for PATCH 15-2, for review and commit. Regards, Abhishek Koneru On Mon, 2012-06-25 at 11:26 -0500, Endi Sukma Dewata wrote: > On 6/22/2012 11:12 AM, Abhishek Koneru wrote: > > Please find attached the patch with fixes for review comments given for > > PATCH 15 for review. > > A few more issues: > > 13. In PasswordCache.java:204 the "r" should be checked for null because > the FileReader() constructor could fail. > > 14. In HttpClient.java:173-180 there's a new try-catch block that > swallows the exception, changing the original behavior. The original > code would let the caller handle the exception. This code was added in > the first patch but only partially reverted in the second patch. It's > always good to compare the cumulative patch against the original code > (e.g. git diff ). > > The try-catch block in line 121-170 doesn't seem to be correct either. I > think it should let the exception be handled by the caller. Feel free to > fix this too, or just leave it as is because this is outside the scope > of this patch. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0015-3-Fixes-for-comments-for-Patch-15-2.patch Type: text/x-patch Size: 7316 bytes Desc: not available URL: From edewata at redhat.com Mon Jun 25 18:40:02 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 25 Jun 2012 13:40:02 -0500 Subject: [Pki-devel] [PATCH] 15-3 Fixes for review comments on -- [PATCH] 15 -2 Fixes for review comments for Patch 15 In-Reply-To: <1340647421.16869.3.camel@abhishek> References: <1340215198.2544.2.camel@abhishek> <4FE3B197.1090208@redhat.com> <1340381527.11863.2.camel@abhishek> <4FE89125.8020603@redhat.com> <1340647421.16869.3.camel@abhishek> Message-ID: <4FE8B082.9020702@redhat.com> On 6/25/2012 1:03 PM, Abhishek Koneru wrote: > Please find attached the patch with fixes for review comments given for > PATCH 15-2, for review and commit. ACK. Merged & pushed to master. -- Endi S. Dewata From akoneru at redhat.com Mon Jun 25 22:24:12 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 25 Jun 2012 18:24:12 -0400 Subject: [Pki-devel] [PATCH] 16 Fixes for Coverity Issues of type Forward Null for DogTag 10 fro review. Message-ID: <1340663052.17537.2.camel@abhishek> Please find attached the patch with fixes for Forward_Null type issues in Coverity for DogTag 10 fro review. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0016-Fixes-for-Forward-Null-Cases-in-Coverity-for-DogTag1.patch Type: text/x-patch Size: 18259 bytes Desc: not available URL: From akoneru at redhat.com Tue Jun 26 15:23:22 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 26 Jun 2012 11:23:22 -0400 Subject: [Pki-devel] [PATCH] 17 Added Null Value Handling for all implementations of IDBAttrMapper: mapObjectToLDAPAttributeSet as part of Forward Null Coverity Fixes for DogTag10 Message-ID: <1340724202.16742.3.camel@abhishek> Please find attached the patch which handles null object passed to map to an LDAP Attribute for review. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0017-Fix-for-handling-null-object-value-passed-to-DBAttrM.patch Type: text/x-patch Size: 25497 bytes Desc: not available URL: From alee at redhat.com Tue Jun 26 16:50:12 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 26 Jun 2012 12:50:12 -0400 Subject: [Pki-devel] [PATCH] Add LDAP cert publisher using LDAP auth DN In-Reply-To: <4FCE6D94.9030905@gtri.gatech.edu> References: <4FCE6D94.9030905@gtri.gatech.edu> Message-ID: <1340729413.16242.11.camel@aleeredhat.laptop> Thanks Josh. I have opened https://fedorahosted.org/pki/ticket/210 to track this. Ade On Tue, 2012-06-05 at 16:35 -0400, Joshua Roys wrote: > Hello, > > Attached is a patch that I've just tested locally to publish certs to a > LDAP directory easily if you have also setup authentication for user > certs using LDAP. I noticed an attribute stored in the internal db > which was the full DN of the authenticated user and that's what this > uses. (I also specify a predicate on the publish rule of > profileId==caDirUserDualCert to restrict the candidate certs to the > proper set.) > > Thanks, > > Josh > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From awnuk at redhat.com Tue Jun 26 19:08:15 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 26 Jun 2012 12:08:15 -0700 Subject: [Pki-devel] [Pki-users] researches have stolen an RSA private key from an Gemalto Cyberflex RSA Token In-Reply-To: References: Message-ID: <4FEA089F.9060009@redhat.com> On 06/26/2012 07:06 AM, Fabian Bertholm wrote: > Hi, > > I am not sure what the implications will be but I think the redhat PKI > system is at least using the same hardware. > You should read this paper. > http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf > > What does this mean for us as users? The following response was provided by Robert Relyea: For most token users, nothing. The researchers have not extracted the RSA private key, they extracted a symmetric key that is encrypted to the private key on the token. In environments where the token does not support decrypt, and operate on FIPS level-3 or above, this is big news, but for deployments which use a basic "RSA-op" function, not even separate Sign/Decrypt functions, you can simply decrypt the blob and get the symmetric key. The paper is definitely worthy of attention, but for most deployments it will have little or now impact. > > Best regard, > Fabian Bertholm > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Jun 26 20:47:33 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 26 Jun 2012 16:47:33 -0400 Subject: [Pki-devel] PATCH 34-1 - Restful interface to create certificate requests Message-ID: <1340743654.16242.18.camel@aleeredhat.laptop> Please review. Tests done: 1. Cert issuance and approval from UI (manual, maul dual cert, agent authenticated server cert) 2. Cert issuance in installation of other subsystems 3. Cert issuance (user and server) from RA. 4. Cert issuance and approval from restful interface using CATest -- two step (create cert request/ agent approval) user and server certs -- single step (agent approved user and server certs) Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0034-1-Adding-restful-interface-to-create-certificate-reque.patch Type: text/x-patch Size: 268499 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 27 00:15:03 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Jun 2012 19:15:03 -0500 Subject: [Pki-devel] [PATCH] 65 Added cert revocation REST service. In-Reply-To: <4FD0BA95.5030503@redhat.com> References: <4FD0BA95.5030503@redhat.com> Message-ID: <4FEA5087.3000402@redhat.com> On 6/7/2012 9:28 AM, Endi Sukma Dewata wrote: > The cert revocation REST service is based on DoRevoke and DoUnrevoke > servlets. It provides an interface to manage certificate revocation. > > Ticket #161 New patch attached. The servlets and REST service have been refactored to use a common processor. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0065-1-Added-cert-revocation-REST-service.patch Type: text/x-patch Size: 172646 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 27 00:15:07 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Jun 2012 19:15:07 -0500 Subject: [Pki-devel] [PATCH] 66 Added cert revocation CLI. In-Reply-To: <4FD0BAA0.4020600@redhat.com> References: <4FD0BAA0.4020600@redhat.com> Message-ID: <4FEA508B.6020903@redhat.com> On 6/7/2012 9:28 AM, Endi Sukma Dewata wrote: > The cert revocation CLI provides a tool to revoke and unrevoke > certificates. > > Ticket #161 New patch attached. The CLI has been renamed to cert-revoke, cert-hold, and cert-release-hold. Permanent revocation will trigger a confirmation prompt. Self-signed CA cert cannot be revoked. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0066-1-Added-cert-revocation-CLI.patch Type: text/x-patch Size: 28500 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 27 00:15:14 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 26 Jun 2012 19:15:14 -0500 Subject: [Pki-devel] [PATCH] 67 Added REST error handler. In-Reply-To: <4FD0BAAE.80907@redhat.com> References: <4FD0BAAE.80907@redhat.com> Message-ID: <4FEA5092.5030501@redhat.com> On 6/7/2012 9:29 AM, Endi Sukma Dewata wrote: > If a REST method returns a Response object it has to be handled > manually. A new getEntity() method has been added to obtain the > entity from the Response object and also map HTTP errors into > exceptions. > > Ticket #161 New patch attached. Same code, revised patch description. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0067-1-Added-REST-error-handler.patch Type: text/x-patch Size: 7276 bytes Desc: not available URL: From alee at redhat.com Wed Jun 27 02:32:34 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 26 Jun 2012 22:32:34 -0400 Subject: [Pki-devel] [PATCH] 69 Fixed problem removing user certificate. In-Reply-To: <4FDFC26E.9010304@redhat.com> References: <4FDFC26E.9010304@redhat.com> Message-ID: <1340764355.13073.1.camel@aleeredhat.laptop> ACK Please close relevant trac ticket as well. Ade On Mon, 2012-06-18 at 19:06 -0500, Endi Sukma Dewata wrote: > Generally the user LDAP entry does not contain a seeAlso attribute > unless it's a special database user. The UGSubsystem.removeUserCert() > would fail because it tried to remove the seeAlso attribute. Now the > code has been fixed to remove the seeAlso using a separate modify > operation and ignore the error if it fails due to missing attribute. > > Ticket #182 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Jun 27 03:58:48 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 26 Jun 2012 23:58:48 -0400 Subject: [Pki-devel] [PATCH] 16 Fixes for Coverity Issues of type Forward Null for DogTag 10 fro review. In-Reply-To: <1340663052.17537.2.camel@abhishek> References: <1340663052.17537.2.camel@abhishek> Message-ID: <1340769529.13073.19.camel@aleeredhat.laptop> Some comments: 1. In CMSEngine.java (getPasswordStore()) , you solve one case where a null pointer dereference can take place (i.e. the exception thrown). But there is another. What happens if mPasswordStore == null and pwdClass == null ? Can pwdClass be null? If not, then we should remove the conditional. 2. In JssSubsystem.java, when throwing the exceptions, add the name of the function. An example is in getCACerts(). In getCACerts(), there is also a formatting problem: certs = CryptoManager.getInstance().getCACerts(); This happens in a bunch of places in this file -- please fix these. 3. Your solution in X509CRLImpl.java is not very intuitive. I prefer a simple check ... if ((sigProvider != null) && (sigProvider.equals("...")) { .. 4. In GenericASN1Extension.java, rather than initializing s to "", I would prefer to keep the initialization to null. You will then need an explicit check for s == null after reading from the file. If s is still null at that point, return "" 5. In DRMTool.java, I'm not convinced your solution preserves the original intent of the code. There is a difference between previous_line = null and previous_line = "". I would suggest that you talk with mharmsen to find the correct solution to this problem. On Mon, 2012-06-25 at 18:24 -0400, Abhishek Koneru wrote: > Please find attached the patch with fixes for Forward_Null type issues > in Coverity for DogTag 10 fro review. > > Regards, > Abhishek Koneru > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Jun 27 15:15:48 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Jun 2012 10:15:48 -0500 Subject: [Pki-devel] [PATCH] 69 Fixed problem removing user certificate. In-Reply-To: <1340764355.13073.1.camel@aleeredhat.laptop> References: <4FDFC26E.9010304@redhat.com> <1340764355.13073.1.camel@aleeredhat.laptop> Message-ID: <4FEB23A4.3080303@redhat.com> On 6/26/2012 9:32 PM, Ade Lee wrote: > ACK > > Please close relevant trac ticket as well. > Ade Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Wed Jun 27 16:15:32 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Jun 2012 11:15:32 -0500 Subject: [Pki-devel] [PATCH] 17 Added Null Value Handling for all implementations of IDBAttrMapper: mapObjectToLDAPAttributeSet as part of Forward Null Coverity Fixes for DogTag10 In-Reply-To: <1340724202.16742.3.camel@abhishek> References: <1340724202.16742.3.camel@abhishek> Message-ID: <4FEB31A4.3000200@redhat.com> On 6/26/2012 10:23 AM, Abhishek Koneru wrote: > Please find attached the patch which handles null object passed to map > to an LDAP Attribute for review. 1. In DateArrayMapper.java:68 to be consistent let's check the original parameter obj instead of dates and move it to the beginning of the method. 2. Formatting issue in KeyRecordMapper.java:62. 3. In LongMapper.LongToDB() the patch checks for null parameter then return a null. The original code would have thrown an exception. For mapObjectToLDAPAttributeSet() it doesn't matter because the null obj is checked earlier, but there are other places that call LongToDB() directly and probably expect an exception. I'd suggest we revert this particular change. 4. This is not a problem, so you don't have to change it. Just FYI, in RequestRecord.java:501 instead of replacing close() with flush() you could also move the next statement outside of the try-finally block. This way it guarantees that the stream is already closed before you use it. 5. In RequestRecord.java:511 the exception was added inside a commented block: //if (Debug.ON) { ... throw new EBaseException(...); //} Suppose one day the block is uncommented, the exception will be thrown only during debugging. I'd suggest we move it after the block. -- Endi S. Dewata From alee at redhat.com Wed Jun 27 19:42:34 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 27 Jun 2012 15:42:34 -0400 Subject: [Pki-devel] [PATCH] 65 Added cert revocation REST service. In-Reply-To: <4FEA5087.3000402@redhat.com> References: <4FD0BA95.5030503@redhat.com> <4FEA5087.3000402@redhat.com> Message-ID: <1340826155.13073.49.camel@aleeredhat.laptop> Some initial comments: (Many of these have been mentioned on irc already) 1. In revokeCert(), you should throw BadRequestException() or similar rather than EBaseException if the cert being revoked is the CA cert, or if the cert is already revoked. That should show up as a 4XX error. 2. It looks like you do not handle nonces. We need a task to figure out how to do this. 3. There is still a fair amount of logic that is in the legacy servlet and RESTful servlet. I would suggest moving the logic that checks whether or not the cert should be revoked - ie. is already revoked, or ca cert already revoked or belongs to different subject or is a system cert to processor.addCertificateToRevoke() or some similar method. You can use exceptions/ returns to populate rarg appropriately in the legacy servlet. 4. What happens if the request is pending or rejected -- ie. not completed. How would the client know? Should we be returning some kind of revocation status object? Or the revocation request itself? I do like the fact that the RevocationProcessor inherits from Processor. We'll need to square up my ProfileProcessor to do the same thing. Ade On Tue, 2012-06-26 at 19:15 -0500, Endi Sukma Dewata wrote: > On 6/7/2012 9:28 AM, Endi Sukma Dewata wrote: > > The cert revocation REST service is based on DoRevoke and DoUnrevoke > > servlets. It provides an interface to manage certificate revocation. > > > > Ticket #161 > > New patch attached. The servlets and REST service have been refactored > to use a common processor. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Jun 27 20:22:45 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 27 Jun 2012 16:22:45 -0400 Subject: [Pki-devel] [PATCH] 67 Added REST error handler. In-Reply-To: <4FEA5092.5030501@redhat.com> References: <4FD0BAAE.80907@redhat.com> <4FEA5092.5030501@redhat.com> Message-ID: <1340828566.13073.51.camel@aleeredhat.laptop> ACK .. tested by trying to add a user twice. [root at alee-workpc profile_test]# pki -p 9410 user-add agent2 --email agent2 at redhat.com --fullName "Agent Two" --password redhat123 --phone 5551212 CMSException: Failed to add user It would be nice if the exception told me why the user was not added. Perhaps you can revisit the user exception code and make sure its descriptive enough -- In this case, it fails because I tried to add the same user twice. On Tue, 2012-06-26 at 19:15 -0500, Endi Sukma Dewata wrote: > On 6/7/2012 9:29 AM, Endi Sukma Dewata wrote: > > If a REST method returns a Response object it has to be handled > > manually. A new getEntity() method has been added to obtain the > > entity from the Response object and also map HTTP errors into > > exceptions. > > > > Ticket #161 > > New patch attached. Same code, revised patch description. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Jun 27 22:51:13 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Jun 2012 17:51:13 -0500 Subject: [Pki-devel] [PATCH] 67 Added REST error handler. In-Reply-To: <1340828566.13073.51.camel@aleeredhat.laptop> References: <4FD0BAAE.80907@redhat.com> <4FEA5092.5030501@redhat.com> <1340828566.13073.51.camel@aleeredhat.laptop> Message-ID: <4FEB8E61.60109@redhat.com> On 6/27/2012 3:22 PM, Ade Lee wrote: > ACK .. tested by trying to add a user twice. Rebased and pushed to master. Thanks. > [root at alee-workpc profile_test]# pki -p 9410 user-add agent2 --email > agent2 at redhat.com --fullName "Agent Two" --password redhat123 --phone > 5551212 > CMSException: Failed to add user > > It would be nice if the exception told me why the user was not added. > Perhaps you can revisit the user exception code and make sure its > descriptive enough -- In this case, it fails because I tried to add the > same user twice. The original failure is most likely caused by LDAP exception (entry already exists). The error description is recorded in the log, but it's not returned to the client (same behavior as in the original servlet). The server returns a message CMS_USRGRP_USER_ADD_FAILED which doesn't contain a space to put the error description. This will be fixed in this ticket: https://fedorahosted.org/pki/ticket/214 -- Endi S. Dewata From edewata at redhat.com Thu Jun 28 14:52:07 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 28 Jun 2012 09:52:07 -0500 Subject: [Pki-devel] PATCH 34-1 - Restful interface to create certificate requests In-Reply-To: <1340743654.16242.18.camel@aleeredhat.laptop> References: <1340743654.16242.18.camel@aleeredhat.laptop> Message-ID: <4FEC6F97.6010805@redhat.com> On 6/26/2012 3:47 PM, Ade Lee wrote: > Please review. > > Tests done: > 1. Cert issuance and approval from UI (manual, maul dual cert, agent > authenticated server cert) > 2. Cert issuance in installation of other subsystems > 3. Cert issuance (user and server) from RA. > 4. Cert issuance and approval from restful interface using CATest > -- two step (create cert request/ agent approval) user and server certs > -- single step (agent approved user and server certs) Some comments, more to follow. Some of these might have been discussed previously. 1. Some fields in the ProfileProcessor are initialized to null in the field declaration. This is not necessary because it's null by default. 2. The code in ProfileProcessor.java:1450 might fail because statEvents could still be null if an error happens before the first startTiming() is called. It might be better to initialize statEvents in the field declaration instead of in startTiming(). Alternatively, it's possible to track the timing without statEvents using a separate try-finally block for each startTiming() & and endTiming() pair: startTiming("enrollment"); try { ... startTiming("request_population"); try { ... } finally { endTiming("request_population"); } ... } finally { endTiming("enrollment"); } 3. Not sure if this is a problem. In ProfileProcessor.java:721 the errorCode is initialized to null before the loop. Inside the loop the errorCode is set when there's an exception but never reset to null again. So if one request fails and the next one succeeds it will still have the errorCode of the previous failure. The errorCode determines whether to call markAsServiced() or updateRequest(). The original servlet has the same behavior. 4. The serial_num in ProfileProcessor.java:412 seems to be used for renewal only. It might be better to move it into processRenewal(). 5. In ProfileProcessor the ps.getProfile() is called multiple times to get the profile. Usually it's using the profileId specified in the request (line 415) but it can be overriden by the configuration (lines 460 & 555). However, the profile inputs are always obtained from the profile specified in the request (line 417). So it's possible the inputs won't match the profile. It might be better to check the configuration when creating the EnrollmentRequestData then subsequent code will use the one specified in it. -- Endi S. Dewata From akoneru at redhat.com Thu Jun 28 16:38:18 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 28 Jun 2012 12:38:18 -0400 Subject: [Pki-devel] [PATCH] 18, 19 - Fixes for Guarded_By_Violation[18] and Unfinished NULL_RETURNS and RESOURCE_LEAKS[19] cases in Coverity for DogTag10 Message-ID: <1340901498.2257.10.camel@abhishek> Please review the patches 18 and 19 with fixes for Guarded_By_Violation[18] and Remaining Null_Returns and ResourceLeaks cases in Coverity for DogTag10. Regards, Abhishek Koneru -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0018-Fixes-for-Guarded_By_Violation-issues-shown-in-Cover.patch Type: text/x-patch Size: 15628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0019-LeftOver-Cases-in-Resource-Leaks-and-NULL_RETURNS.patch Type: text/x-patch Size: 17285 bytes Desc: not available URL: From akoneru at redhat.com Thu Jun 28 19:27:09 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 28 Jun 2012 15:27:09 -0400 Subject: [Pki-devel] [Patch] 16-2 Fixes for review comments on -- [PATCH] 16 Fixes for Coverity Issues of type Forward Null for DogTag 10 fro review. In-Reply-To: <1340769529.13073.19.camel@aleeredhat.laptop> References: <1340663052.17537.2.camel@abhishek> <1340769529.13073.19.camel@aleeredhat.laptop> Message-ID: <1340911629.2257.15.camel@abhishek> Please review the attached patch with fixes for the below comments. Regards, Abhishek Koneru On Tue, 2012-06-26 at 23:58 -0400, Ade Lee wrote: > Some comments: > > 1. In CMSEngine.java (getPasswordStore()) , you solve one case where a > null pointer dereference can take place (i.e. the exception thrown). > But there is another. What happens if mPasswordStore == null and > pwdClass == null ? Can pwdClass be null? If not, then we should remove > the conditional. > > 2. In JssSubsystem.java, when throwing the exceptions, add the name of > the function. An example is in getCACerts(). In getCACerts(), there is > also a formatting problem: > > certs = > CryptoManager.getInstance().getCACerts(); > > This happens in a bunch of places in this file -- please fix these. > > 3. Your solution in X509CRLImpl.java is not very intuitive. I prefer a > simple check ... > if ((sigProvider != null) && (sigProvider.equals("...")) { .. > > 4. In GenericASN1Extension.java, rather than initializing s to "", I > would prefer to keep the initialization to null. You will then need an > explicit check for s == null after reading from the file. If s is still > null at that point, return "" > > 5. In DRMTool.java, I'm not convinced your solution preserves the > original intent of the code. There is a difference between > previous_line = null and previous_line = "". I would suggest that you > talk with mharmsen to find the correct solution to this problem. > > On Mon, 2012-06-25 at 18:24 -0400, Abhishek Koneru wrote: > > Please find attached the patch with fixes for Forward_Null type issues > > in Coverity for DogTag 10 fro review. > > > > Regards, > > Abhishek Koneru > > _______________________________________________ > > 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-0016-2-Fixes-for-review-comments-for-Patch16.patch Type: text/x-patch Size: 23062 bytes Desc: not available URL: From akoneru at redhat.com Thu Jun 28 19:35:32 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 28 Jun 2012 15:35:32 -0400 Subject: [Pki-devel] [PATCH] 17-2 Fixes for review comments on -- [PATCH] 17 Added Null Value Handling for all implementations of IDBAttrMapper: mapObjectToLDAPAttributeSet as part of Forward Null Coverity Fixes for DogTag10 In-Reply-To: <4FEB31A4.3000200@redhat.com> References: <1340724202.16742.3.camel@abhishek> <4FEB31A4.3000200@redhat.com> Message-ID: <1340912132.2257.17.camel@abhishek> Please review the patch 17-2 with fixes for review comments given for Patch 17. Regards, Abhishek Koneru On Wed, 2012-06-27 at 11:15 -0500, Endi Sukma Dewata wrote: > On 6/26/2012 10:23 AM, Abhishek Koneru wrote: > > Please find attached the patch which handles null object passed to map > > to an LDAP Attribute for review. > > 1. In DateArrayMapper.java:68 to be consistent let's check the original > parameter obj instead of dates and move it to the beginning of the method. > > 2. Formatting issue in KeyRecordMapper.java:62. > > 3. In LongMapper.LongToDB() the patch checks for null parameter then > return a null. The original code would have thrown an exception. For > mapObjectToLDAPAttributeSet() it doesn't matter because the null obj is > checked earlier, but there are other places that call LongToDB() > directly and probably expect an exception. I'd suggest we revert this > particular change. > > 4. This is not a problem, so you don't have to change it. Just FYI, in > RequestRecord.java:501 instead of replacing close() with flush() you > could also move the next statement outside of the try-finally block. > This way it guarantees that the stream is already closed before you use it. > > 5. In RequestRecord.java:511 the exception was added inside a commented > block: > > //if (Debug.ON) { > ... > throw new EBaseException(...); > //} > > Suppose one day the block is uncommented, the exception will be thrown > only during debugging. I'd suggest we move it after the block. > From akoneru at redhat.com Thu Jun 28 19:36:50 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 28 Jun 2012 15:36:50 -0400 Subject: [Pki-devel] [PATCH] 17-2 Fixes for review comments on -- [PATCH] 17 Added Null Value Handling for all implementations of IDBAttrMapper: mapObjectToLDAPAttributeSet as part of Forward Null Coverity Fixes for DogTag10 In-Reply-To: <1340912132.2257.17.camel@abhishek> References: <1340724202.16742.3.camel@abhishek> <4FEB31A4.3000200@redhat.com> <1340912132.2257.17.camel@abhishek> Message-ID: <1340912210.2257.18.camel@abhishek> Sorry for the spam. Forgot to add the patch. Thanks, Abhishek Koneru On Thu, 2012-06-28 at 15:35 -0400, Abhishek Koneru wrote: > Please review the patch 17-2 with fixes for review comments given for > Patch 17. > > Regards, > Abhishek Koneru > On Wed, 2012-06-27 at 11:15 -0500, Endi Sukma Dewata wrote: > > On 6/26/2012 10:23 AM, Abhishek Koneru wrote: > > > Please find attached the patch which handles null object passed to map > > > to an LDAP Attribute for review. > > > > 1. In DateArrayMapper.java:68 to be consistent let's check the original > > parameter obj instead of dates and move it to the beginning of the method. > > > > 2. Formatting issue in KeyRecordMapper.java:62. > > > > 3. In LongMapper.LongToDB() the patch checks for null parameter then > > return a null. The original code would have thrown an exception. For > > mapObjectToLDAPAttributeSet() it doesn't matter because the null obj is > > checked earlier, but there are other places that call LongToDB() > > directly and probably expect an exception. I'd suggest we revert this > > particular change. > > > > 4. This is not a problem, so you don't have to change it. Just FYI, in > > RequestRecord.java:501 instead of replacing close() with flush() you > > could also move the next statement outside of the try-finally block. > > This way it guarantees that the stream is already closed before you use it. > > > > 5. In RequestRecord.java:511 the exception was added inside a commented > > block: > > > > //if (Debug.ON) { > > ... > > throw new EBaseException(...); > > //} > > > > Suppose one day the block is uncommented, the exception will be thrown > > only during debugging. I'd suggest we move it after the block. > > > > > _______________________________________________ > 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-0017-2-Fixes-for-Review-Comments-for-PATCH-17.patch Type: text/x-patch Size: 5861 bytes Desc: not available URL: From alee at redhat.com Fri Jun 29 04:47:04 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 29 Jun 2012 00:47:04 -0400 Subject: [Pki-devel] PATCH 34-1 - Restful interface to create certificate requests In-Reply-To: <4FEC6F97.6010805@redhat.com> References: <1340743654.16242.18.camel@aleeredhat.laptop> <4FEC6F97.6010805@redhat.com> Message-ID: <1340945224.32284.17.camel@aleeredhat.laptop> I have attached an updated patch to address the comments (see below). In addition, the patch: * modifies the restful interface for approve/reject etc. from /certrequest/approve to /certrequest/{id}/approve * removes an unneeded class and some unneeded annotations. * changes the name of one class (PolicyAttribute) to ProfileAttribute and uses this class in new jaxb model classes for ProfileOutputs * adds ProfileOutputs to the AgentEnrollmentRequestData class. * Refactors the ProfileProcess servlet to use the ProfileProcessor. Please review. The attached patch replaces the existing patch. Thanks, Ade On Thu, 2012-06-28 at 09:52 -0500, Endi Sukma Dewata wrote: > On 6/26/2012 3:47 PM, Ade Lee wrote: > > Please review. > > > > Tests done: > > 1. Cert issuance and approval from UI (manual, maul dual cert, agent > > authenticated server cert) > > 2. Cert issuance in installation of other subsystems > > 3. Cert issuance (user and server) from RA. > > 4. Cert issuance and approval from restful interface using CATest > > -- two step (create cert request/ agent approval) user and server certs > > -- single step (agent approved user and server certs) > > Some comments, more to follow. Some of these might have been discussed > previously. > > 1. Some fields in the ProfileProcessor are initialized to null in the > field declaration. This is not necessary because it's null by default. > done. > 2. The code in ProfileProcessor.java:1450 might fail because statEvents > could still be null if an error happens before the first startTiming() > is called. It might be better to initialize statEvents in the field > declaration instead of in startTiming(). Alternatively, it's possible to > track the timing without statEvents using a separate try-finally block > for each startTiming() & and endTiming() pair: > > startTiming("enrollment"); > try { > ... > startTiming("request_population"); > try { > ... > } finally { > endTiming("request_population"); > } > ... > } finally { > endTiming("enrollment"); > } > fixed. initialized in the field declaration. > 3. Not sure if this is a problem. In ProfileProcessor.java:721 the > errorCode is initialized to null before the loop. Inside the loop the > errorCode is set when there's an exception but never reset to null > again. So if one request fails and the next one succeeds it will still > have the errorCode of the previous failure. The errorCode determines > whether to call markAsServiced() or updateRequest(). The original > servlet has the same behavior. > This is tricky -- the behavior is less than ideal but I specifically left it this way because thats what the original servlet did. We can discuss if/how we should fix it. > 4. The serial_num in ProfileProcessor.java:412 seems to be used for > renewal only. It might be better to move it into processRenewal(). > done. > 5. In ProfileProcessor the ps.getProfile() is called multiple times to > get the profile. Usually it's using the profileId specified in the > request (line 415) but it can be overriden by the configuration (lines > 460 & 555). However, the profile inputs are always obtained from the > profile specified in the request (line 417). So it's possible the inputs > won't match the profile. It might be better to check the configuration > when creating the EnrollmentRequestData then subsequent code will use > the one specified in it. > good catch. done. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0034-2-Adding-restful-interface-to-create-certificate-reque.patch Type: text/x-patch Size: 312593 bytes Desc: not available URL: From alee at redhat.com Fri Jun 29 05:30:04 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 29 Jun 2012 01:30:04 -0400 Subject: [Pki-devel] [Patch] 16-2 Fixes for review comments on -- [PATCH] 16 Fixes for Coverity Issues of type Forward Null for DogTag 10 fro review. In-Reply-To: <1340911629.2257.15.camel@abhishek> References: <1340663052.17537.2.camel@abhishek> <1340769529.13073.19.camel@aleeredhat.laptop> <1340911629.2257.15.camel@abhishek> Message-ID: <1340947804.32284.18.camel@aleeredhat.laptop> ACK - pushed to master. On Thu, 2012-06-28 at 15:27 -0400, Abhishek Koneru wrote: > Please review the attached patch with fixes for the below comments. > > Regards, > Abhishek Koneru > On Tue, 2012-06-26 at 23:58 -0400, Ade Lee wrote: > > Some comments: > > > > 1. In CMSEngine.java (getPasswordStore()) , you solve one case where a > > null pointer dereference can take place (i.e. the exception thrown). > > But there is another. What happens if mPasswordStore == null and > > pwdClass == null ? Can pwdClass be null? If not, then we should remove > > the conditional. > > > > 2. In JssSubsystem.java, when throwing the exceptions, add the name of > > the function. An example is in getCACerts(). In getCACerts(), there is > > also a formatting problem: > > > > certs = > > CryptoManager.getInstance().getCACerts(); > > > > This happens in a bunch of places in this file -- please fix these. > > > > 3. Your solution in X509CRLImpl.java is not very intuitive. I prefer a > > simple check ... > > if ((sigProvider != null) && (sigProvider.equals("...")) { .. > > > > 4. In GenericASN1Extension.java, rather than initializing s to "", I > > would prefer to keep the initialization to null. You will then need an > > explicit check for s == null after reading from the file. If s is still > > null at that point, return "" > > > > 5. In DRMTool.java, I'm not convinced your solution preserves the > > original intent of the code. There is a difference between > > previous_line = null and previous_line = "". I would suggest that you > > talk with mharmsen to find the correct solution to this problem. > > > > On Mon, 2012-06-25 at 18:24 -0400, Abhishek Koneru wrote: > > > Please find attached the patch with fixes for Forward_Null type issues > > > in Coverity for DogTag 10 fro review. > > > > > > Regards, > > > Abhishek Koneru > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > From edewata at redhat.com Fri Jun 29 15:29:11 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 29 Jun 2012 10:29:11 -0500 Subject: [Pki-devel] PATCH 34-1 - Restful interface to create certificate requests In-Reply-To: <1340945224.32284.17.camel@aleeredhat.laptop> References: <1340743654.16242.18.camel@aleeredhat.laptop> <4FEC6F97.6010805@redhat.com> <1340945224.32284.17.camel@aleeredhat.laptop> Message-ID: <4FEDC9C7.8080009@redhat.com> On 6/28/2012 11:47 PM, Ade Lee wrote: > I have attached an updated patch to address the comments (see below). > In addition, the patch: > * modifies the restful interface for approve/reject etc. > from /certrequest/approve to /certrequest/{id}/approve > * removes an unneeded class and some unneeded annotations. > * changes the name of one class (PolicyAttribute) to ProfileAttribute > and uses this class in new jaxb model classes for ProfileOutputs > * adds ProfileOutputs to the AgentEnrollmentRequestData class. > * Refactors the ProfileProcess servlet to use the ProfileProcessor. > > Please review. The attached patch replaces the existing patch. More comments: 6. The ProfileProcessor is very big creating maintenance issue. It probably can be split into smaller classes that handle specific actions, e.g. CertEnrollmentProcessor, CertRenewalProcessor, CertApprovalProcessor. Common fields & methods could be moved into a Processor base class. 7. The DAO layer doesn't seem to be necessary because it used exclusively by the REST service and the majority of work is done in Processor layer. I guess when we merge the plural and singular REST service later we can merge DAO too. 8. The ProfileProcessor can use the Auditor service to simplify the auditing code. Is this going to be done separately? 9. In ProfileServlet the statEvents is initialized in startTiming. It's safer to initialize it in the field declaration as in ProfileProcessor. 10. To be consistent XML element name should be capitalized and XML attribute names should be lower case, for example: ... 11. Since REST data model is going to be shared with the client, it should not depend on classes that are used for the server only. This is not a problem now because certserv package contains both shared and server-only classes, but they will be difficult to separate later if the shared classes depend on server-only classes. For example PolicyDefault is a REST data model, but it depends on IRequest which is most likely a server-only interface. It might be better to have a separate factory class (e.g. PolicyDefaultFactory) which can construct a PolicyDefault object and then set its attributes with values obtained from server-only objects. 12. Formatting issue in CARestClient.java:125, PolicyConstraint.java:41. -- Endi S. Dewata From edewata at redhat.com Fri Jun 29 19:22:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 29 Jun 2012 14:22:53 -0500 Subject: [Pki-devel] [PATCH] 17-2 Fixes for review comments on -- [PATCH] 17 Added Null Value Handling for all implementations of IDBAttrMapper: mapObjectToLDAPAttributeSet as part of Forward Null Coverity Fixes for DogTag10 In-Reply-To: <1340912210.2257.18.camel@abhishek> References: <1340724202.16742.3.camel@abhishek> <4FEB31A4.3000200@redhat.com> <1340912132.2257.17.camel@abhishek> <1340912210.2257.18.camel@abhishek> Message-ID: <4FEE008D.6020107@redhat.com> On 6/28/2012 2:36 PM, Abhishek Koneru wrote: > Sorry for the spam. Forgot to add the patch. > Thanks, > Abhishek Koneru > On Thu, 2012-06-28 at 15:35 -0400, Abhishek Koneru wrote: >> Please review the patch 17-2 with fixes for review comments given for >> Patch 17. ACK. Merged & pushed to master. -- Endi S. Dewata From edewata at redhat.com Sat Jun 30 01:39:04 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 29 Jun 2012 20:39:04 -0500 Subject: [Pki-devel] [PATCH] 18, 19 - Fixes for Guarded_By_Violation[18] and Unfinished NULL_RETURNS and RESOURCE_LEAKS[19] cases in Coverity for DogTag10 In-Reply-To: <1340901498.2257.10.camel@abhishek> References: <1340901498.2257.10.camel@abhishek> Message-ID: <4FEE58B8.6040804@redhat.com> On 6/28/2012 11:38 AM, Abhishek Koneru wrote: > Please review the patches 18 and 19 with fixes for > Guarded_By_Violation[18] and Remaining Null_Returns and ResourceLeaks > cases in Coverity for DogTag10. As discussed over IRC, the GUARDED_BY_VIOLATION issue happens if a field is synchronized in one location but not in other location. This can be fixed by adding synchronized block, synchronizing the whole method, or removing the original synchronization (if it's not actually needed). However, if we make the synchronization too broad, it may include other fields that weren't originally synchronized, which might trigger new GUARDED_BY_VIOLATION issues. For now I think we should focus on synchronizing the offending fields only as reported by Coverity because if we start synchronizing other fields it may have some unintended consequences. If there are fields that should have been synchronized but they aren't, they should investigated & fixed in separate tickets. For patch #18 the following methods should be fixed to lock 'this' object and synchronize the following fields only: * ARequestNotifier.recoverPublishingQueue(): mSearchForRequests * CrossCertPairSubsystem.init(): mPublisherProcessor * CertificateRepository.setCertStatusUpdateInterval(): requestRepository * DBVirtualList.setSortKey(): mRegistry * KeyRepository.setKeyStatusUpdateInterval(): requestRepository * MD5.init(): buffer For patch #19: 1. In CertificateAuthority.java:1899,1943 it throws an exception with log message instead of user message. I don't see a suitable user message for this so it might be better to just re-throw the original exception and let the caller handle it. 2. In FileBasedPublisher.java:384 the fos.close() shouldn't be moved because subsequent code depends on it. I think the "fos" instances in this method should be handled by separate try-finally blocks. 3. In KeyRepository.java:518 the patch checks for null recList but this might not sufficient because in line 534 the recList is read again. It might be better to throw EBaseException if it's null. -- Endi S. Dewata