From alee at redhat.com Mon Oct 1 12:51:57 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Oct 2012 08:51:57 -0400 Subject: [Pki-devel] [PATCH] 126 Added package checking for pkispawn and pkidestroy. In-Reply-To: <50670914.7070202@redhat.com> References: <50653826.1050301@redhat.com> <1348840980.2575.75.camel@aleeredhat.laptop> <1348841290.2575.79.camel@aleeredhat.laptop> <50670914.7070202@redhat.com> Message-ID: <1349095918.2575.85.camel@aleeredhat.laptop> ACK On Sat, 2012-09-29 at 09:43 -0500, Endi Sukma Dewata wrote: > On 9/28/2012 9:08 AM, Ade Lee wrote: > > actually .. its ok to check for the package pki-ca etc. when you want to > > pkispawn an instance. But maybe, we do not want to do this check when > > executing pkidestroy. > > > > After all someone might remove the rpm. and then try to clean up the > > instances. As far as I know, there isn't any reason for them not to be > > able to do that. > > > > Ade > > New patch attached. As discussed, we might move some deployment files > into the subsystem package in the future so pkidestroy may require the > subsystem package to be installed. But for now I've moved the code from > pkiparse.py into pkispawn so the checking is done in pkispawn only. > From alee at redhat.com Mon Oct 1 13:43:10 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Oct 2012 09:43:10 -0400 Subject: [Pki-devel] [PATCH] 128 Using RPM version number in CMake. In-Reply-To: <506886D9.1090804@redhat.com> References: <506886D9.1090804@redhat.com> Message-ID: <1349098991.2575.90.camel@aleeredhat.laptop> Endi, I see how the logic is supposed to work, but when I build using the compose packages, I still see 10.0.0 as the implementation version. Ade On Sun, 2012-09-30 at 12:52 -0500, Endi Sukma Dewata wrote: > The RPM spec files have been modified to pass the full RPM version > number to CMake. The version number contains the product version > number, release number, milestone, and platform. The CMake scritps > will parse and use this version number to generate Java manifest > files. The product version number will be used as the specification > version and full version number will be used as the implementation > version. > > Ticket #339 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon Oct 1 14:09:13 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 01 Oct 2012 09:09:13 -0500 Subject: [Pki-devel] [PATCH] 125 Fixed synchronization problem in CertificateRepository. In-Reply-To: <5065E9F6.70006@redhat.com> References: <50627274.7010304@redhat.com> <5065E9F6.70006@redhat.com> Message-ID: <5069A409.6020301@redhat.com> On 9/28/2012 1:18 PM, Andrew Wnuk wrote: > On 09/25/2012 08:11 PM, Endi Sukma Dewata wrote: >> Some synchronized methods in CertificateRepository have been moved >> into CertStatusUpdateThread to avoid blocking other synchronized >> methods too long. >> >> Ticket #313 > NACK. > > processRevokedCerts - seems to be use only by CRLIssuingPoint and it is > not used by CertificateRepository maintenance thread therefore I so not > reason to move processRevokedCerts to CertStatusUpdateTask. Just to clarify the IRC discussion last week, this patch is supposed to address the long blocking issue by reverting to Dogtag 9 behavior, assuming the Dogtag 9 has the correct behavior. In Dogtag 9 the processRevokedCerts() exists in CRLIssuingPoint class as shown in this simplified code: public void processRevokedCerts(IElementProcessor p) { // NOTE: dangerous cast. // correct way would be to modify interface and add // accessor but we don't want to touch the interface CertificateRepository cr = (CertificateRepository)mCertRepository; synchronized (cr.mCertStatusUpdateThread) { CMS.debug("Starting processRevokedCerts (entered lock)"); list = mCertRepository.findCertRecordsInList(...); list.processCertRecords(...); CMS.debug("processRevokedCerts done"); } } There are some issues in the above code: 1. In Dogtag 9 the mCertRepository is being downcasted to CertificateRepository. As indicated by the comment in the code this is dangerous and we are supposed to modify the ICertificateRepository interface. In Dogtag 10 this was fixed by adding a new method called processRevokedCerts() into the interface so it's no longer necessary to downcast mCertRepository. The above code will now look like this: public void processRevokedCerts(IElementProcessor p) { mCertRepository.processRevokedCerts(...); } 2. In Dogtag 9 the code locks the mCertStatusUpdateThread which is an attribute of the mCertRepository. This is not a good OO practice because it's breaking the encapsulation. We could add a method getCertStatusUpdateThread() but it's still not a good solution because the thread class is a private class of CertificateRepository. The CRLIssuingPoint isn't supposed to see the thread object. This patch addresses this issue by moving the above code into CertificateRepository's processRevokedCerts(). This way the certificate repository can lock its own thread without breaking encapsulation. public void processRevokedCerts(IElementProcessor p) { synchronized (mCertStatusUpdateThread) { CMS.debug("Starting processRevokedCerts (entered lock)"); list = this.findCertRecordsInList(...); list.processCertRecords(...); CMS.debug("processRevokedCerts done"); } } This, however, is not the final code. See the following point. 3. In Dogtag 9 the locking is done using a synchronized block. While it works just fine, the code could be implemented with a synchronized method which would be cleaner: the object being locked is implicit, and here we block the whole method which has a well defined boundary, instead of a piece of code in the middle of a method. With this patch the Dogtag 10 is supposed to have the same behavior as Dogtag 9 that they both guarantee mutual exclusion of the following code: list = this.findCertRecordsInList(...); list.processCertRecords(...); and the following code: _cr.updateCertStatus(); _cr.checkRanges(); _rr.checkRanges(); And the execution of either of the above code wouldn't block modifyCertificateRecord(). It would be difficult to prove correctness of undeterministic code by testing. Testing would prove if there's an error in the code, but no error even after extensive testing doesn't mean it's correct. The best way to review this patch is I think by analyzing the code, following the logic, comparing with previous code, and some basic testing. -- Endi S. Dewata From alee at redhat.com Mon Oct 1 14:44:05 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Oct 2012 10:44:05 -0400 Subject: [Pki-devel] [PATCH] 125 Fixed synchronization problem in CertificateRepository. In-Reply-To: <5069A409.6020301@redhat.com> References: <50627274.7010304@redhat.com> <5065E9F6.70006@redhat.com> <5069A409.6020301@redhat.com> Message-ID: <1349102645.2575.102.camel@aleeredhat.laptop> On Mon, 2012-10-01 at 09:09 -0500, Endi Sukma Dewata wrote: > On 9/28/2012 1:18 PM, Andrew Wnuk wrote: > > On 09/25/2012 08:11 PM, Endi Sukma Dewata wrote: > >> Some synchronized methods in CertificateRepository have been moved > >> into CertStatusUpdateThread to avoid blocking other synchronized > >> methods too long. > >> > >> Ticket #313 > > > NACK. > > > > processRevokedCerts - seems to be use only by CRLIssuingPoint and it is > > not used by CertificateRepository maintenance thread therefore I so not > > reason to move processRevokedCerts to CertStatusUpdateTask. > > Just to clarify the IRC discussion last week, this patch is supposed to > address the long blocking issue by reverting to Dogtag 9 behavior, > assuming the Dogtag 9 has the correct behavior. > > In Dogtag 9 the processRevokedCerts() exists in CRLIssuingPoint class as > shown in this simplified code: > > public void processRevokedCerts(IElementProcessor p) { > > // NOTE: dangerous cast. > // correct way would be to modify interface and add > // accessor but we don't want to touch the interface > > CertificateRepository cr = (CertificateRepository)mCertRepository; > > synchronized (cr.mCertStatusUpdateThread) { > CMS.debug("Starting processRevokedCerts (entered lock)"); > > list = mCertRepository.findCertRecordsInList(...); > list.processCertRecords(...); > > CMS.debug("processRevokedCerts done"); > } > } > > There are some issues in the above code: > > 1. In Dogtag 9 the mCertRepository is being downcasted to > CertificateRepository. As indicated by the comment in the code this is > dangerous and we are supposed to modify the ICertificateRepository > interface. In Dogtag 10 this was fixed by adding a new method called > processRevokedCerts() into the interface so it's no longer necessary to > downcast mCertRepository. The above code will now look like this: > > public void processRevokedCerts(IElementProcessor p) { > mCertRepository.processRevokedCerts(...); > } > > 2. In Dogtag 9 the code locks the mCertStatusUpdateThread which is an > attribute of the mCertRepository. This is not a good OO practice because > it's breaking the encapsulation. We could add a method > getCertStatusUpdateThread() but it's still not a good solution because > the thread class is a private class of CertificateRepository. The > CRLIssuingPoint isn't supposed to see the thread object. This patch > addresses this issue by moving the above code into > CertificateRepository's processRevokedCerts(). This way the certificate > repository can lock its own thread without breaking encapsulation. > > public void processRevokedCerts(IElementProcessor p) { > synchronized (mCertStatusUpdateThread) { > CMS.debug("Starting processRevokedCerts (entered lock)"); > > list = this.findCertRecordsInList(...); > list.processCertRecords(...); > > CMS.debug("processRevokedCerts done"); > } > } > > This, however, is not the final code. See the following point. > > 3. In Dogtag 9 the locking is done using a synchronized block. While it > works just fine, the code could be implemented with a synchronized > method which would be cleaner: the object being locked is implicit, and > here we block the whole method which has a well defined boundary, > instead of a piece of code in the middle of a method. > I agree with points 1 and 2. It makes sense to have processCertRecords() as a method within CertificateRepository, so that it can lock its own private thread. I would be OK with the code in point 2 above. I'm not sure I agree that locking using a synchronized method is any cleaner though. The patch moves code which does not is not executed by the maintenance thread into the maintenance thread, purely for the sake of elucidating synchronization. The maintenance thread should contain only the methods that it executes. > With this patch the Dogtag 10 is supposed to have the same behavior as > Dogtag 9 that they both guarantee mutual exclusion of the following code: > > list = this.findCertRecordsInList(...); > list.processCertRecords(...); > > and the following code: > > _cr.updateCertStatus(); > _cr.checkRanges(); > _rr.checkRanges(); > > And the execution of either of the above code wouldn't block > modifyCertificateRecord(). > > It would be difficult to prove correctness of undeterministic code by > testing. Testing would prove if there's an error in the code, but no > error even after extensive testing doesn't mean it's correct. The best > way to review this patch is I think by analyzing the code, following the > logic, comparing with previous code, and some basic testing. > From edewata at redhat.com Mon Oct 1 16:05:45 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 01 Oct 2012 11:05:45 -0500 Subject: [Pki-devel] [PATCH] 126 Added package checking for pkispawn and pkidestroy. In-Reply-To: <1349095918.2575.85.camel@aleeredhat.laptop> References: <50653826.1050301@redhat.com> <1348840980.2575.75.camel@aleeredhat.laptop> <1348841290.2575.79.camel@aleeredhat.laptop> <50670914.7070202@redhat.com> <1349095918.2575.85.camel@aleeredhat.laptop> Message-ID: <5069BF59.5020805@redhat.com> On 10/1/2012 7:51 AM, Ade Lee wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Oct 1 17:46:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 01 Oct 2012 12:46:41 -0500 Subject: [Pki-devel] [PATCH] 128 Using RPM version number in CMake. In-Reply-To: <1349098991.2575.90.camel@aleeredhat.laptop> References: <506886D9.1090804@redhat.com> <1349098991.2575.90.camel@aleeredhat.laptop> Message-ID: <5069D701.8060103@redhat.com> On 10/1/2012 8:43 AM, Ade Lee wrote: > Endi, > > I see how the logic is supposed to work, but when I build using the > compose packages, I still see 10.0.0 as the implementation version. > > Ade > On Sun, 2012-09-30 at 12:52 -0500, Endi Sukma Dewata wrote: >> The RPM spec files have been modified to pass the full RPM version >> number to CMake. The version number contains the product version >> number, release number, milestone, and platform. The CMake scritps >> will parse and use this version number to generate Java manifest >> files. The product version number will be used as the specification >> version and full version number will be used as the implementation >> version. >> >> Ticket #339 New patch attached. Removed old code that overrides the version. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0128-1-Using-RPM-version-number-in-CMake.patch Type: text/x-patch Size: 30107 bytes Desc: not available URL: From alee at redhat.com Mon Oct 1 18:16:56 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Oct 2012 14:16:56 -0400 Subject: [Pki-devel] [PATCH] 128 Using RPM version number in CMake. In-Reply-To: <5069D701.8060103@redhat.com> References: <506886D9.1090804@redhat.com> <1349098991.2575.90.camel@aleeredhat.laptop> <5069D701.8060103@redhat.com> Message-ID: <1349115416.2575.112.camel@aleeredhat.laptop> ack -- pushed to master On Mon, 2012-10-01 at 12:46 -0500, Endi Sukma Dewata wrote: > On 10/1/2012 8:43 AM, Ade Lee wrote: > > Endi, > > > > I see how the logic is supposed to work, but when I build using the > > compose packages, I still see 10.0.0 as the implementation version. > > > > Ade > > On Sun, 2012-09-30 at 12:52 -0500, Endi Sukma Dewata wrote: > >> The RPM spec files have been modified to pass the full RPM version > >> number to CMake. The version number contains the product version > >> number, release number, milestone, and platform. The CMake scritps > >> will parse and use this version number to generate Java manifest > >> files. The product version number will be used as the specification > >> version and full version number will be used as the implementation > >> version. > >> > >> Ticket #339 > > New patch attached. Removed old code that overrides the version. > From edewata at redhat.com Tue Oct 2 17:11:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 02 Oct 2012 12:11:23 -0500 Subject: [Pki-devel] [PATCH] 129 Added Provides to packages replacing obsolete packages. Message-ID: <506B203B.6020202@redhat.com> Packages that replaced old packages have been modified to specify "Provides" to satisfy dependency on the old packages. Ticket #336 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0129-Added-Provides-to-packages-replacing-obsolete-packag.patch Type: text/x-patch Size: 2822 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 2 17:19:26 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 02 Oct 2012 12:19:26 -0500 Subject: [Pki-devel] [PATCH] 129 Added Provides to packages replacing obsolete packages. In-Reply-To: <506B203B.6020202@redhat.com> References: <506B203B.6020202@redhat.com> Message-ID: <506B221E.9000903@redhat.com> On 10/2/2012 12:11 PM, Endi Sukma Dewata wrote: > Packages that replaced old packages have been modified to specify > "Provides" to satisfy dependency on the old packages. > > Ticket #336 ACKed by Ade. Pushed to master. -- Endi S. Dewata From alee at redhat.com Wed Oct 3 02:44:29 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 02 Oct 2012 22:44:29 -0400 Subject: [Pki-devel] Announcing Dogtag 10.0.0 alpha 2 release Message-ID: <1349232270.27199.7.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 alpha 2. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.37.a2.fc18 pki-ra-10.0.0-0.8.a2.fc18 pki-tps-10.0.0-0.8.a2.fc18 dogtag-pki-10.0.0-0.9.a2.fc18 dogtag-pki-theme-10.0.0-0.2.a2.fc18 pki-console-10.0.0-0.8.a2.fc18 == Highlights since Dogtag v. 10.0.0 alpha 1 (Sept 14 2012) == * Dogtag 10 can now clone from Dogtag 9 masters. We will fall back to the old installation servlet if needed. (**) * Startup state of a server can be determined from the getStatus() servlet (**) * Consistent database user provided during installation for client authentication (used in IPA merged database install) * Fixed package dependency issue with pki-symkey (**) * pki-setup merged into pki-server (**) * Audit Cert Renewal time extended to two years (**) * Versioning added to jar manifest files and VERSION file and reported in getStatus * ECC enhancements in DRM and TMS environment * Addition of time based searches in preparation for randomized serial numbers * Enhanced escaping of LDAP attributes * Improved transition control for token operations in the TPS. ** denotes IPA related/reported issue == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == Ade Lee (4): 761a047 Updated release to a2 854ecce fall back to old interface for installtoken if needed 11e05d3 Use getStatus servlet to provide startup status e1666df Changes to use standard dbuser Andrew Wnuk (1): f944641 time based searches Christina Fu (5): 7b3df7e https://fedorahosted.org/pki/ticket/252 - TMS - ECC Key Recovery 528fda5 TMS key recovery part of - Bug 737122 - DRM: during archiving and recovering, wrapping unwrapping keys should be done in the token f4ecf48 (fixed warning for) task #304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) e689561 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) 6257d32 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) Endi Dewata (11): f81718c Using RPM version number in CMake. aa1c7e7 Added package checking for pkispawn. 87d290d Added version number into server status. 9368ef4 Added VERSION file. 1726794 Renamed escapeDN() into escapeRDNValue(). 4ba74f7 Merged pki-setup into pki-server. 156ba56 Added DN and filter escaping in ConfigurationUtils. 947ab8a Removed duplicate DN escaping methods. 715d89d Added DN and filter escaping in UGSubsystem. 7b737b2 Fixed conflicting log4j.properties. 8ed86a7 Fixed problems with optional pki-symkey. Jack Magne (1): 9173b43 Provide default for operations transition list, # 858816. Matthew Harmsen (2): d450525 Correctly resolve symlinks in subdirectories f5b8ea5 Audit Cert Renewal From edewata at redhat.com Wed Oct 3 23:01:36 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 03 Oct 2012 18:01:36 -0500 Subject: [Pki-devel] [PATCH] 130 Enabled Tomcat security manager. Message-ID: <506CC3D0.10806@redhat.com> The tomcat.conf and pkideployment.cfg have been modified to enable the security manager. The catalina.policy has been updated with more specific permissions for PKI. Ticket #223 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0130-Enabled-Tomcat-security-manager.patch Type: text/x-patch Size: 5932 bytes Desc: not available URL: From alee at redhat.com Fri Oct 5 04:59:19 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 00:59:19 -0400 Subject: [Pki-devel] [PATCH] add missing link for d9 -> d10 instance Message-ID: <1349413159.2357.10.camel@aleeredhat.laptop> Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0064-Added-needed-link-for-updated-d9-d10-instances.patch Type: text/x-patch Size: 1167 bytes Desc: not available URL: From alee at redhat.com Fri Oct 5 05:10:15 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 01:10:15 -0400 Subject: [Pki-devel] [PATCH] 60-63 revised selinux policy Message-ID: <1349413816.19017.2.camel@aleeredhat.laptop> Apply patches in order. This adds the selinux policy which is likely to be added to the system policy for all subsystems. Please try it out in permissive mode and note any avcs generated. Also includes: - required code to get ra and tps instances started. - cleanup code for pid file management for the java subsystems Notes: 1. On f18, everything works as expected. 2. On f17, there are two issues a) the needed selinux-policy has been built in koji but is not in updates yet. I will bug mgrepl about this in the morning. b) the pid file fixes will break java subsystem startup because of a bug in tomcat. https://bugzilla.redhat.com/show_bug.cgi?id=863307 I will be pushing for this to be fixed asap. In the meantime, you will need to modify /usr/sbin/tomcat-sysd and replace export CATALINA_PID="/var/run/${NAME}.pid" with: export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}" Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0063-Changes-to-start-pki_ra-and-pki_tps-in-correct-conte.patch Type: text/x-patch Size: 13119 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0062-add-selinux-context-for-pkidaemon-remove-unneeded-pi.patch Type: text/x-patch Size: 9675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0061-move-common-policy-into-tps-ra-templates.patch Type: text/x-patch Size: 18929 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0060-Use-the-tomcat-selinux-domain-for-the-Java-processes.patch Type: text/x-patch Size: 15911 bytes Desc: not available URL: From alee at redhat.com Fri Oct 5 19:42:32 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 15:42:32 -0400 Subject: [Pki-devel] [PATCH] add missing link for d9 -> d10 instance In-Reply-To: <1349413159.2357.10.camel@aleeredhat.laptop> References: <1349413159.2357.10.camel@aleeredhat.laptop> Message-ID: <1349466153.19017.32.camel@aleeredhat.laptop> acked by endi. Pushed to master. On Fri, 2012-10-05 at 00:59 -0400, Ade Lee wrote: > Please review. > > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Oct 5 20:04:07 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 05 Oct 2012 16:04:07 -0400 Subject: [Pki-devel] [PATCH] 60-63 revised selinux policy In-Reply-To: <1349413816.19017.2.camel@aleeredhat.laptop> References: <1349413816.19017.2.camel@aleeredhat.laptop> Message-ID: <1349467448.19017.33.camel@aleeredhat.laptop> acked by Endi. Fixed typo in spec file. Pushed to master. On Fri, 2012-10-05 at 01:10 -0400, Ade Lee wrote: > Apply patches in order. > > This adds the selinux policy which is likely to be added to the system > policy for all subsystems. Please try it out in permissive mode and > note any avcs generated. > > Also includes: > - required code to get ra and tps instances started. > - cleanup code for pid file management for the java subsystems > > Notes: > > 1. On f18, everything works as expected. > 2. On f17, there are two issues > > a) the needed selinux-policy has been built in koji but is not in > updates yet. I will bug mgrepl about this in the morning. > > b) the pid file fixes will break java subsystem startup because of a bug > in tomcat. https://bugzilla.redhat.com/show_bug.cgi?id=863307 > I will be pushing for this to be fixed asap. In the meantime, you will > need to modify /usr/sbin/tomcat-sysd and replace > > export CATALINA_PID="/var/run/${NAME}.pid" > with: > export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}" > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Sat Oct 6 03:40:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 05 Oct 2012 22:40:56 -0500 Subject: [Pki-devel] [PATCH] 131 Renamed "shared" folder to "server". Message-ID: <506FA848.1030806@redhat.com> The "shared" folder in /usr/share/pki has been renamed to "server" since it contains only server files. Ticket #353 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0131-Renamed-shared-folder-to-server.patch Type: text/x-patch Size: 7498 bytes Desc: not available URL: From edewata at redhat.com Sat Oct 6 03:41:00 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 05 Oct 2012 22:41:00 -0500 Subject: [Pki-devel] [PATCH] 132 Merged pki-silent into pki-server. Message-ID: <506FA84C.8040905@redhat.com> The pki-silent package has been merged into pki-server package. Ticket #354 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0132-Merged-pki-silent-into-pki-server.patch Type: text/x-patch Size: 13692 bytes Desc: not available URL: From alee at redhat.com Mon Oct 8 03:54:14 2012 From: alee at redhat.com (Ade Lee) Date: Sun, 07 Oct 2012 23:54:14 -0400 Subject: [Pki-devel] [PATCH] 131 Renamed "shared" folder to "server". In-Reply-To: <506FA848.1030806@redhat.com> References: <506FA848.1030806@redhat.com> Message-ID: <1349668454.19017.39.camel@aleeredhat.laptop> ack. pushed to master On Fri, 2012-10-05 at 22:40 -0500, Endi Sukma Dewata wrote: > The "shared" folder in /usr/share/pki has been renamed > to "server" since it contains only server files. > > Ticket #353 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 8 03:54:31 2012 From: alee at redhat.com (Ade Lee) Date: Sun, 07 Oct 2012 23:54:31 -0400 Subject: [Pki-devel] [PATCH] 132 Merged pki-silent into pki-server. In-Reply-To: <506FA84C.8040905@redhat.com> References: <506FA84C.8040905@redhat.com> Message-ID: <1349668472.19017.40.camel@aleeredhat.laptop> ack - pushed to master On Fri, 2012-10-05 at 22:41 -0500, Endi Sukma Dewata wrote: > The pki-silent package has been merged into pki-server package. > > Ticket #354 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 8 13:39:01 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 08 Oct 2012 09:39:01 -0400 Subject: [Pki-devel] PATCH - 65 - backup CS.cfg befor d10 update Message-ID: <1349703541.19017.44.camel@aleeredhat.laptop> pviktorin had a weird (and unreproduced) case, where during an upgrade from d9 -> d10, and ipa 2.2 -> ipa 3, the CS.cfg was blanked. As a temporary mitigation step in case this happens again, we will save the old CS.cfg when the update steps are performed. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0065-Backup-CS.cfg-before-d10-update.patch Type: text/x-patch Size: 967 bytes Desc: not available URL: From alee at redhat.com Mon Oct 8 14:04:51 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 08 Oct 2012 10:04:51 -0400 Subject: [Pki-devel] PATCH - 65 - backup CS.cfg befor d10 update In-Reply-To: <1349703541.19017.44.camel@aleeredhat.laptop> References: <1349703541.19017.44.camel@aleeredhat.laptop> Message-ID: <1349705092.19017.45.camel@aleeredhat.laptop> changed file to .CS.cfg.dogtag9 as suggested by Endi. Acked by Endi - pushed to master. On Mon, 2012-10-08 at 09:39 -0400, Ade Lee wrote: > pviktorin had a weird (and unreproduced) case, where during an upgrade > from d9 -> d10, and ipa 2.2 -> ipa 3, the CS.cfg was blanked. > > As a temporary mitigation step in case this happens again, we will save > the old CS.cfg when the update steps are performed. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Oct 9 14:31:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 09 Oct 2012 09:31:53 -0500 Subject: [Pki-devel] [PATCH] 133 Added PKIConnection. Message-ID: <50743559.4040201@redhat.com> The code in PKIClient has been refactored into PKIConnection such that a single connection object can be used by several REST clients. The PKIClient will remain the base class for all REST clients. Ticket #357 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0133-Added-PKIConnection.patch Type: text/x-patch Size: 34754 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 9 14:31:58 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 09 Oct 2012 09:31:58 -0500 Subject: [Pki-devel] [PATCH] 134 Added PKIPrincipal. Message-ID: <5074355E.2000703@redhat.com> Previously in PKIRealm the authentication token was stored in a thread local variable. This does not work for multiple operations executed using the same session because each operation may be handled by different threads. A new PKIPrincipal has been added to store the authentication token so that the threads can get the correct token for the session. Ticket #357 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0134-Added-PKIPrincipal.patch Type: text/x-patch Size: 7298 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 9 14:32:03 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 09 Oct 2012 09:32:03 -0500 Subject: [Pki-devel] [PATCH] 135 Added REST account service. Message-ID: <50743563.4020807@redhat.com> A REST account service has been added to allow client to login to establish a session and to logout to destroy the session. This way multiple operations can be executed using the same session without having to re-authenticate. Ticket #357 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0135-Added-REST-account-service.patch Type: text/x-patch Size: 20557 bytes Desc: not available URL: From alee at redhat.com Tue Oct 9 15:03:40 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 09 Oct 2012 11:03:40 -0400 Subject: [Pki-devel] Announcing Dogtag 10.0.0 beta 1 release Message-ID: <1349795021.19017.102.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 beta 1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.43.b1.fc18 pki-ra-10.0.0-0.9.b1.fc18 pki-tps-10.0.0-0.9.b1.fc18 dogtag-pki-10.0.0-0.10.b1.fc18 dogtag-pki-theme-10.0.0-0.2.b1.fc18 pki-console-10.0.0-0.8.b1.fc18 == Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) == * Merged pki-silent into pki-server. * Added Provides to packages replacing obsolete packages. * Added needed link for updated d9 -> d10 instances. Found in IPA testing. * Backed up CS.cfg before upgrading from d9 -> d10 * New selinux policy for all components. The Java components now take advantage of a tomcat domain defined in the base selinux policy, and the RA/TPS policies have been cleaned up considerably. The policy that is now delivered is very close to the final version that will be delivered in the base policy. That will be a deliverable for beta 2. * Selinux context for startup scripts for all components set so that runcon is not required. * Cleaned up lock and pid files generation and removal for java processes. * Rebuilt packages against the latest F18 base selinux policy packages to resolve an issue in installing pki-selinux due to removal of a boolean in F18 base selinux policies. This issue was reported by IPA. == Notes for F17 == * F17 requires an selinux version that is still in updates-testing. Enable this repo to upgrade accordingly. * F17 tomcat has a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Prior to creating an instance, you need to perform the following workaround: In the file, /usr/sbin/tomcat-sysd, change the line: export CATALINA_PID="/var/run/${NAME}.pid" to: export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}" == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == Ade Lee (11): 5ef10ba Update selinux-policy version to fix error from latest policy 81596ba fix spec typo 919434b Added build requires for version of selinux-policy-devel 5014442 Update release to b1 9cd11bc Fix name of CS.cfg backup file 63237d3 Backup CS.cfg before d10 update da73f97 Changes to start pki_ra and pki_tps in correct context 6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code f542060 move common policy into tps, ra templates dbc6dec Use the tomcat selinux domain for the Java processes 3d5dc3b Added needed link for updated d9 -> d10 instances Endi Dewata (3): 23c70bd Merged pki-silent into pki-server. 79a3d82 Renamed "shared" folder to "server". 753d55e Added Provides to packages replacing obsolete packages. From edewata at redhat.com Tue Oct 9 21:00:06 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 09 Oct 2012 16:00:06 -0500 Subject: [Pki-devel] [PATCH] 136 Enabled realm authentication for certificate requests. Message-ID: <50749056.4080001@redhat.com> The realm authentication on certificate request REST services has been enabled. Since now in the CLI the authentication is done using a separate login operation, it is now possible to POST the approval data without the problem related to chunked message. Ticket #300 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0136-Enabled-realm-authentication-for-certificate-request.patch Type: text/x-patch Size: 3515 bytes Desc: not available URL: From edewata at redhat.com Wed Oct 10 01:14:16 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 09 Oct 2012 20:14:16 -0500 Subject: [Pki-devel] [PATCH] 137 Fixed KRA test. Message-ID: <5074CBE8.5080405@redhat.com> The security configuration, JAXB mappings, and test script for KRA have been updated to run properly. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0137-Fixed-KRA-test.patch Type: text/x-patch Size: 9380 bytes Desc: not available URL: From alee at redhat.com Wed Oct 10 04:40:57 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 10 Oct 2012 00:40:57 -0400 Subject: [Pki-devel] [PATCH] 66 - selinux changes for pki_tomcat_cert_t Message-ID: <1349844058.19017.115.camel@aleeredhat.laptop> Added some missing selinux rules found during ipa installation, as well as a new type pki_tomcat_cert_t for the NSS certificate databases. Added an selinux interface and permissions for certmonger to read and write to those files. Also added the pkispawn and pkidestroy logic to label files for non-default instances. I have pushed to master so that IPA can test the changes from the nightly build, and so that mgrepl can get the latest policy to do a test scratch build in the morning. But please review notwithstanding. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0066-Added-pki_tomcat_cert_t-type-and-interface-to-access.patch Type: text/x-patch Size: 8317 bytes Desc: not available URL: From cfu at redhat.com Wed Oct 10 21:01:12 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 10 Oct 2012 14:01:12 -0700 Subject: [Pki-devel] [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>, <50627A89.9080407@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> <50647FFF.9000001@redhat.com>, <5069FB89.6070606@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com> Message-ID: <5075E218.5070404@redhat.com> Hi Jamil, We branched off of JSS 4.2.6 and created several patches ever since. Merging with upstream JSS (4.3) has been planned to be done within the next year also. Until then, we are not able to provide information with confidence on how JSS4.3 would work with our current releases. If any Dogtag community member has tried and has answer for you, it would be great. Christina On 10/10/2012 09:54 AM, Nimeh, Jamil wrote: > > [Re-reply to include pki-devel at redhat.com ] > > Hi Christina, sorry for taking so long to get back to you. I can file > this against JSS, but given that it's a down-rev version (4.2.6) and > appears to be fixed in JSS 4.3, is it worth filing this? > > I guess the bigger question that affects SHA-2 algorithms as they are > implemented in Dogtag is whether or not I can safely use JSS 4.3 with > Dogtag 9.0.x? 4.2.6 is what appears to be the latest rev in the F15 > yum repositories. Do you (or anyone on your team maybe) know if there > are incompatibilities between JSS 4.2.6 and 4.3 that would break a > Dogtag 9 installation? > > If it can work the areas that this would affect would be: > > * Proper creation of SCEP CertRep messages when using SHA-2 algs > * The ability to sign OCSP responses using something other than > SHA-1 (can that be changed? I don't see a tuneable for this) > * The ability to submit CMC revocation messages using SHA-2 and > have it properly validated before acting on it in the CA. > > There might be other areas as well (maybe in other CMC related > functions) but those three areas are the ones I've run into. > > > Thanks, > > Jamil > > ------------------------------------------------------------------------ > *From:* pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on > behalf of Christina Fu [cfu at redhat.com] > *Sent:* Monday, October 01, 2012 1:22 PM > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages > failing to verify on server > > Hi Jamil, > > I see the issue now. I agree there is an issue with the OID. In > fact, the hashalg (2) is missing from not just SHA256, but also SHA384 > and SHA512 as well. > > Please go ahead and file a bug for JSS so it could be scheduled for > future release. It will probably be automatically assigned to me by > default. > > thanks, > Christina > > On 09/27/2012 09:34 AM, Christina Fu wrote: >> Hi Jamil, >> >> I am running a variant of jss-4.2.6-23 (with one extra patch that I >> have not had time to push/build, but it has nothing to do with your >> suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I >> develop on RHEL. >> >> Yes, if you'd send in your code with precise reproducing steps, I >> might be able to look into it sooner. >> >> Christina >> >> On 09/25/2012 11:10 PM, Nimeh, Jamil wrote: >>> Hi Christina, thank you very much for getting back to me. >>> >>> I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. >>> That seems to work across the board with JSS and Dogtag (otherwise I >>> could never sign a cert with SHA-256, I suppose). I'd be curious to >>> know what version of JSS is on your RHEL/RHCS8.1 machine, and >>> perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS >>> 3.13.4. Maybe something different between the bits we're running? >>> >>> I've run into the issue when a PKCS#7 or CMS signedData message is >>> created. In those cases, the SHA-256 OID would normally be asserted >>> in two locations: >>> 1. In the DigestAlgorithmIdentifiers segment of the SignedData >>> object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly >>> asserted here. >>> >>> 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see >>> RFC 5652 5.3): This is where the OID gets messed up with SHA-2 >>> algs. Since there is only one signer, the >>> DigestAlgorithmIdentifiers section at the beginning would have only >>> one OID, the SHA-256 one, and that OID should be repeated again in >>> the SignerInfo. >>> >>> What happens though is that the SignerInfo's >>> DigestAlgorithmIdentifier will show up with an OID of >>> 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This >>> appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6 >>> is what comes down when the dogtag packages are pulled with yum, so >>> I wasn't sure if I could pop in a newer JSS safely. >>> >>> Tomorrow I'll take my doctored up CMCRevoke and cook up two >>> messages, one where I load the 4.2.6 JSS and one where I do 4.3 and >>> I'll send you the DER encodings so you can see what I'm talking >>> about. I don't recall, but I think the bug report for 824624 might >>> have sample SCEP CertRep messages from the CA, which show the issue >>> using PKCS#7. >>> >>> Once again, thank you very much for taking the time to look at this. >>> >>> --Jamil >>> >>> ------------------------------------------------------------------------ >>> *From:* pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] >>> on behalf of Christina Fu [cfu at redhat.com] >>> *Sent:* Tuesday, September 25, 2012 8:46 PM >>> *To:* pki-users at redhat.com >>> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages >>> failing to verify on server >>> >>> Hi Jamil, >>> >>> I tried to reproduce your issue, but I seemed to be able to generate >>> CMC revocation request with SHA-256 digest. I have to admit that my >>> main development machine is RHEL and I work on RHCS8.1 tree. >>> >>> I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the >>> exception with DSA), compiled, and it just worked. Did you do >>> anything different? >>> >>> I could see in dumpasn1 where SHA245 is in place: >>> C-Sequence (13) >>> Object Identifier (9) >>> 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) >>> NULL (0) >>> Christina >>> >>> On 09/19/2012 11:19 AM, Christina Fu wrote: >>>> Hi Jamil, >>>> >>>> We made an effort to support SHA2 where we can but might have >>>> missed a few places. I'll look into this and hopefully be able to >>>> get back to you in a few days. >>>> >>>> thanks, >>>> Christina >>>> >>>> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: >>>>> >>>>> Hello Dogtag Gurus, >>>>> >>>>> I have been trying to issue CMC revocation messages signed with >>>>> SHA-256, but the server fails to validate the message in the >>>>> CMCAuth java policy module. If I leave all fields the same but >>>>> change the signature algorithm to SHA-1 then everything seems to >>>>> work fine. >>>>> >>>>> I suspect this is another side-effect of the root-cause for bug >>>>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 >>>>> messages are created using any of the SHA-2 variants, the OIDs get >>>>> messed up. This happened with SCEP responses from the CA (the bug >>>>> referenced above) and I had it happen with the CMC revoke >>>>> modifications I made. The latter issue was fixed by pulling down >>>>> JSS 4.3 and loading that jar in the classpath for the modified >>>>> CMCRevoke tool. However, on the server side I ended up seeing >>>>> verification failures. >>>>> >>>>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one >>>>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with >>>>> JSS 4.3 or later. Is that still the case with the latest 9.0 >>>>> packages? >>>>> >>>>> >>>>> Has anyone had any success generating these CMC messages using >>>>> SHA-2 hash algs and getting Dogtag to accept them? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jamil >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pki-users mailing list >>>>> Pki-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> >>>> >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >>> >> >> >> _______________________________________________ >> 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 prmarino1 at gmail.com Wed Oct 10 22:43:52 2012 From: prmarino1 at gmail.com (Paul Robert Marino) Date: Wed, 10 Oct 2012 18:43:52 -0400 Subject: [Pki-devel] Announcing Dogtag 10.0.0 beta 1 release In-Reply-To: <1349795021.19017.102.camel@aleeredhat.laptop> References: <1349795021.19017.102.camel@aleeredhat.laptop> Message-ID: Are there any plans to port this version to EL6 after the official release? On Oct 9, 2012 11:03 AM, "Ade Lee" wrote: > The Dogtag team is proud to announce version Dogtag v10.0.0 beta 1. > > A build is available for Fedora 18 in the updates-testing repo. Please > try it out and provide karma to move it to the F18 stable repo. > > Daily developer builds for Fedora 17 and 18 are available at > http://nkinder.fedorapeople.org/dogtag-devel/fedora/ > > == Build Versions == > pki-core-10.0.0-0.43.b1.fc18 > pki-ra-10.0.0-0.9.b1.fc18 > pki-tps-10.0.0-0.9.b1.fc18 > dogtag-pki-10.0.0-0.10.b1.fc18 > dogtag-pki-theme-10.0.0-0.2.b1.fc18 > pki-console-10.0.0-0.8.b1.fc18 > > == Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) == > > * Merged pki-silent into pki-server. > * Added Provides to packages replacing obsolete packages. > * Added needed link for updated d9 -> d10 instances. Found in IPA > testing. > * Backed up CS.cfg before upgrading from d9 -> d10 > * New selinux policy for all components. The Java components now take > advantage of a tomcat domain defined in the base selinux policy, and > the RA/TPS policies have been cleaned up considerably. The policy that > is > now delivered is very close to the final version that will be delivered > in the base policy. That will be a deliverable for beta 2. > * Selinux context for startup scripts for all components set so that > runcon is not required. > * Cleaned up lock and pid files generation and removal for java > processes. > * Rebuilt packages against the latest F18 base selinux policy packages > to resolve an issue in installing pki-selinux due to removal of a > boolean in F18 base selinux policies. This issue was reported by IPA. > > == Notes for F17 == > * F17 requires an selinux version that is still in updates-testing. > Enable this repo to upgrade accordingly. > > * F17 tomcat has a bug in the way it handles pid files. > https://bugzilla.redhat.com/show_bug.cgi?id=863307. Prior to creating > an instance, you need to perform the following workaround: > > In the file, /usr/sbin/tomcat-sysd, change the line: > export CATALINA_PID="/var/run/${NAME}.pid" > to: > export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}" > > == Feedback == > > Please provide comments, bugs and other feedback via the pki-devel > mailing list: http://www.redhat.com/mailman/listinfo/pki-devel > > == Detailed Changelog == > > Ade Lee (11): > 5ef10ba Update selinux-policy version to fix error from latest policy > 81596ba fix spec typo > 919434b Added build requires for version of selinux-policy-devel > 5014442 Update release to b1 > 9cd11bc Fix name of CS.cfg backup file > 63237d3 Backup CS.cfg before d10 update > da73f97 Changes to start pki_ra and pki_tps in correct context > 6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code > f542060 move common policy into tps, ra templates > dbc6dec Use the tomcat selinux domain for the Java processes > 3d5dc3b Added needed link for updated d9 -> d10 instances > > Endi Dewata (3): > 23c70bd Merged pki-silent into pki-server. > 79a3d82 Renamed "shared" folder to "server". > 753d55e Added Provides to packages replacing obsolete packages. > > > > _______________________________________________ > 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 Jamil.Nimeh at viasat.com Wed Oct 10 22:15:26 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Wed, 10 Oct 2012 22:15:26 +0000 Subject: [Pki-devel] [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <5075E218.5070404@redhat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>, <50627A89.9080407@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> <50647FFF.9000001@redhat.com>,<5069FB89.6070606@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com>, <5075E218.5070404@redhat.com> Message-ID: <6A95FA630FB5124C886BAD159CDBA1F016D5FF97@wdc1exchmbxp05.hq.corp.viasat.com> Thanks Christina for the feedback. I guess I can give it a try and see what happens. At some point I may have to look into pushing forward to Dogtag 10/Fedora 18 and see if those same issues occur on a newer system. Given that you ran similar tests on other systems and didn't see what I found on F15 maybe an updated system will work. I'll give it a try when I have some spare cycles and let you know. Thanks, Jamil ________________________________ From: Christina Fu [cfu at redhat.com] Sent: Wednesday, October 10, 2012 2:01 PM To: Nimeh, Jamil Cc: pki-devel at redhat.com; pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, We branched off of JSS 4.2.6 and created several patches ever since. Merging with upstream JSS (4.3) has been planned to be done within the next year also. Until then, we are not able to provide information with confidence on how JSS4.3 would work with our current releases. If any Dogtag community member has tried and has answer for you, it would be great. Christina On 10/10/2012 09:54 AM, Nimeh, Jamil wrote: [Re-reply to include pki-devel at redhat.com] Hi Christina, sorry for taking so long to get back to you. I can file this against JSS, but given that it's a down-rev version (4.2.6) and appears to be fixed in JSS 4.3, is it worth filing this? I guess the bigger question that affects SHA-2 algorithms as they are implemented in Dogtag is whether or not I can safely use JSS 4.3 with Dogtag 9.0.x? 4.2.6 is what appears to be the latest rev in the F15 yum repositories. Do you (or anyone on your team maybe) know if there are incompatibilities between JSS 4.2.6 and 4.3 that would break a Dogtag 9 installation? If it can work the areas that this would affect would be: * Proper creation of SCEP CertRep messages when using SHA-2 algs * The ability to sign OCSP responses using something other than SHA-1 (can that be changed? I don't see a tuneable for this) * The ability to submit CMC revocation messages using SHA-2 and have it properly validated before acting on it in the CA. There might be other areas as well (maybe in other CMC related functions) but those three areas are the ones I've run into. Thanks, Jamil ________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on behalf of Christina Fu [cfu at redhat.com] Sent: Monday, October 01, 2012 1:22 PM To: pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, I see the issue now. I agree there is an issue with the OID. In fact, the hashalg (2) is missing from not just SHA256, but also SHA384 and SHA512 as well. Please go ahead and file a bug for JSS so it could be scheduled for future release. It will probably be automatically assigned to me by default. thanks, Christina On 09/27/2012 09:34 AM, Christina Fu wrote: Hi Jamil, I am running a variant of jss-4.2.6-23 (with one extra patch that I have not had time to push/build, but it has nothing to do with your suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I develop on RHEL. Yes, if you'd send in your code with precise reproducing steps, I might be able to look into it sooner. Christina On 09/25/2012 11:10 PM, Nimeh, Jamil wrote: Hi Christina, thank you very much for getting back to me. I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. That seems to work across the board with JSS and Dogtag (otherwise I could never sign a cert with SHA-256, I suppose). I'd be curious to know what version of JSS is on your RHEL/RHCS8.1 machine, and perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS 3.13.4. Maybe something different between the bits we're running? I've run into the issue when a PKCS#7 or CMS signedData message is created. In those cases, the SHA-256 OID would normally be asserted in two locations: 1. In the DigestAlgorithmIdentifiers segment of the SignedData object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly asserted here. 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see RFC 5652 5.3): This is where the OID gets messed up with SHA-2 algs. Since there is only one signer, the DigestAlgorithmIdentifiers section at the beginning would have only one OID, the SHA-256 one, and that OID should be repeated again in the SignerInfo. What happens though is that the SignerInfo's DigestAlgorithmIdentifier will show up with an OID of 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6 is what comes down when the dogtag packages are pulled with yum, so I wasn't sure if I could pop in a newer JSS safely. Tomorrow I'll take my doctored up CMCRevoke and cook up two messages, one where I load the 4.2.6 JSS and one where I do 4.3 and I'll send you the DER encodings so you can see what I'm talking about. I don't recall, but I think the bug report for 824624 might have sample SCEP CertRep messages from the CA, which show the issue using PKCS#7. Once again, thank you very much for taking the time to look at this. --Jamil ________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on behalf of Christina Fu [cfu at redhat.com] Sent: Tuesday, September 25, 2012 8:46 PM To: pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, I tried to reproduce your issue, but I seemed to be able to generate CMC revocation request with SHA-256 digest. I have to admit that my main development machine is RHEL and I work on RHCS8.1 tree. I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the exception with DSA), compiled, and it just worked. Did you do anything different? I could see in dumpasn1 where SHA245 is in place: C-Sequence (13) Object Identifier (9) 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) NULL (0) Christina On 09/19/2012 11:19 AM, Christina Fu wrote: Hi Jamil, We made an effort to support SHA2 where we can but might have missed a few places. I'll look into this and hopefully be able to get back to you in a few days. thanks, Christina On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: Hello Dogtag Gurus, I have been trying to issue CMC revocation messages signed with SHA-256, but the server fails to validate the message in the CMCAuth java policy module. If I leave all fields the same but change the signature algorithm to SHA-1 then everything seems to work fine. I suspect this is another side-effect of the root-cause for bug 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 messages are created using any of the SHA-2 variants, the OIDs get messed up. This happened with SCEP responses from the CA (the bug referenced above) and I had it happen with the CMC revoke modifications I made. The latter issue was fixed by pulling down JSS 4.3 and loading that jar in the classpath for the modified CMCRevoke tool. However, on the server side I ended up seeing verification failures. I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS 4.3 or later. Is that still the case with the latest 9.0 packages? Has anyone had any success generating these CMC messages using SHA-2 hash algs and getting Dogtag to accept them? Thanks, Jamil _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ 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 Thu Oct 11 03:01:08 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 10 Oct 2012 23:01:08 -0400 Subject: [Pki-devel] [PATCH] 67 new selinux interface needed for certmonger to search tomcat_exec_rw_t dirs Message-ID: <1349924468.19017.166.camel@aleeredhat.laptop> Revision to pki-selinux policy. Pushed to master. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0067-New-selinux-interface-needed-for-certmonger-director.patch Type: text/x-patch Size: 2077 bytes Desc: not available URL: From mharmsen at redhat.com Thu Oct 11 23:18:13 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 11 Oct 2012 16:18:13 -0700 Subject: [Pki-devel] Request to build pki-core-9.0.3-26.el6 for RHEL 6.4 in Brew . . . Message-ID: <507753B5.8090101@redhat.com> We would like to request an official build of 'pki-core-9.0.3-26.el6' for RHEL 6.4 in Brew to resolve the following bugs: * *Bugzilla Bug #841663* -serial number incorrectly cast from BigInt to integer in installation wizard * *Bugzilla Bug #844459* -Increase audit cert renewal range to 2 years * *Bugzilla Bug #858864* -create/ identify a mechanism for clients to determine that the pki subsystem is up The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * pki-core-9.0.3-bz771790.patch * pki-core-9.0.3-bz745677.patch * pki-core-9.0.3-bz769388.patch * pki-core-9.0.3-bz802396.patch * pki-core-9.0.3-bz819111.patch * pki-core-9.0.3-bz841663.patch * pki-core-9.0.3-bz844459.patch * pki-core-9.0.3-bz858864.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 46277 bytes Desc: not available URL: From release-engineering at redhat.com Thu Oct 11 23:18:21 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Thu, 11 Oct 2012 19:18:21 -0400 Subject: [Pki-devel] [engineering.redhat.com #172863] Request to build pki-core-9.0.3-26.el6 for RHEL 6.4 in Brew . . . In-Reply-To: <507753B5.8090101@redhat.com> References: <507753B5.8090101@redhat.com> Message-ID: Ticket We would like to request an official build of 'pki-core-9.0.3-26.el6' for RHEL 6.4 in Brew to resolve the following bugs: * *Bugzilla Bug #841663* -serial number incorrectly cast from BigInt to integer in installation wizard * *Bugzilla Bug #844459* -Increase audit cert renewal range to 2 years * *Bugzilla Bug #858864* -create/ identify a mechanism for clients to determine that the pki subsystem is up The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * pki-core-9.0.3-bz771790.patch * pki-core-9.0.3-bz745677.patch * pki-core-9.0.3-bz769388.patch * pki-core-9.0.3-bz802396.patch * pki-core-9.0.3-bz819111.patch * pki-core-9.0.3-bz841663.patch * pki-core-9.0.3-bz844459.patch * pki-core-9.0.3-bz858864.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 46277 bytes Desc: not available URL: From release-engineering at redhat.com Fri Oct 12 00:14:40 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Thu, 11 Oct 2012 20:14:40 -0400 Subject: [Pki-devel] [engineering.redhat.com #172863] Request to build pki-core-9.0.3-26.el6 for RHEL 6.4 in Brew . . . In-Reply-To: <507753B5.8090101@redhat.com> References: <507753B5.8090101@redhat.com> Message-ID: Ticket done: Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4965599 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=238168 From alee at redhat.com Fri Oct 12 03:29:06 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 11 Oct 2012 23:29:06 -0400 Subject: [Pki-devel] [PATCH] 68 - Return to d9 behavior for RetrieveModifications Task Message-ID: <1350012546.19017.183.camel@aleeredhat.laptop> There are problems in the d10 behavior, most likely because of failing to handle cases where the db connection closes or something else untoward happens. Revert to d9 behavior for now, and opening a ticket to fix properly later. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0068-Return-to-d9-behavior-for-RetrieveModificationsTask.patch Type: text/x-patch Size: 1885 bytes Desc: not available URL: From alee at redhat.com Fri Oct 12 03:53:26 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 11 Oct 2012 23:53:26 -0400 Subject: [Pki-devel] [PATCH] 69 - Added pki_tomcat_script_t type and rules to support upgraded instances Message-ID: <1350014006.19017.186.camel@aleeredhat.laptop> The pki_tomcat_script_t and its transition rules are needed to support dogtag 9 style instances that have been upgraded to d10 bits. These instances will still use pkicontrol which does a runcon through pki_tomcat_script_t. Pushed to master. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0069-Added-pki_tomcat_script_t-type-and-rules-to-support-.patch Type: text/x-patch Size: 1435 bytes Desc: not available URL: From alee at redhat.com Fri Oct 12 03:56:14 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 11 Oct 2012 23:56:14 -0400 Subject: [Pki-devel] [PATCH] 68 - Return to d9 behavior for RetrieveModifications Task In-Reply-To: <1350012546.19017.183.camel@aleeredhat.laptop> References: <1350012546.19017.183.camel@aleeredhat.laptop> Message-ID: <1350014174.19017.187.camel@aleeredhat.laptop> acked by Endi - pushed to master. On Thu, 2012-10-11 at 23:29 -0400, Ade Lee wrote: > There are problems in the d10 behavior, most likely because of failing > to handle cases where the db connection closes or something else > untoward happens. > > Revert to d9 behavior for now, and opening a ticket to fix properly > later. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Oct 12 16:10:18 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 12 Oct 2012 12:10:18 -0400 Subject: [Pki-devel] [PATCH] 70 - patch to remind folks to not use pkicreate for new java instances Message-ID: <1350058218.19017.190.camel@aleeredhat.laptop> This is just a quick patch to remind folks in the usage not to use pkicreate for java instances. More people are looking at beta now and making that mistake. There is probably more that could be done, but this will likely suffice for now. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0070-changes-to-remind-folks-not-to-use-pkicreate-pkiremo.patch Type: text/x-patch Size: 11890 bytes Desc: not available URL: From alee at redhat.com Fri Oct 12 16:27:41 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 12 Oct 2012 12:27:41 -0400 Subject: [Pki-devel] [PATCH] 70 - updating tomcatjss deps Message-ID: <1350059262.19017.191.camel@aleeredhat.laptop> Pushed to master. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0071-Update-tomcatjss-dependency.patch Type: text/x-patch Size: 3658 bytes Desc: not available URL: From alee at redhat.com Fri Oct 12 17:54:47 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 12 Oct 2012 13:54:47 -0400 Subject: [Pki-devel] [PATCH] 70 - patch to remind folks to not use pkicreate for new java instances In-Reply-To: <1350058218.19017.190.camel@aleeredhat.laptop> References: <1350058218.19017.190.camel@aleeredhat.laptop> Message-ID: <1350064487.19017.192.camel@aleeredhat.laptop> pushed to master, On Fri, 2012-10-12 at 12:10 -0400, Ade Lee wrote: > This is just a quick patch to remind folks in the usage not to use > pkicreate for java instances. More people are looking at beta now and > making that mistake. > > There is probably more that could be done, but this will likely suffice > for now. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Oct 12 18:07:58 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 12 Oct 2012 14:07:58 -0400 Subject: [Pki-devel] [PATCH] 72 - workaround for the install token problem Message-ID: <1350065278.19017.196.camel@aleeredhat.laptop> As a workaround here, we will go back to the old interface and old httpclient to get an install token. Until we can figure out whats going on with PKIClient on f18 in an ipa install. I'll fix the commit message when I commit. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0072-testing-old-token.patch Type: text/x-patch Size: 3417 bytes Desc: not available URL: From alee at redhat.com Fri Oct 12 20:19:16 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 12 Oct 2012 16:19:16 -0400 Subject: [Pki-devel] [PATCH] 72 - workaround for the install token problem In-Reply-To: <1350065278.19017.196.camel@aleeredhat.laptop> References: <1350065278.19017.196.camel@aleeredhat.laptop> Message-ID: <1350073156.19017.197.camel@aleeredhat.laptop> Made some changes to HttpMessage.java as discussed with Endi. Pushed to master. On Fri, 2012-10-12 at 14:07 -0400, Ade Lee wrote: > As a workaround here, we will go back to the old interface and old > httpclient to get an install token. > > Until we can figure out whats going on with PKIClient on f18 in an ipa > install. > > I'll fix the commit message when I commit. > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Fri Oct 12 23:48:10 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 12 Oct 2012 16:48:10 -0700 Subject: [Pki-devel] Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . Message-ID: <5078AC3A.7060609@redhat.com> We would like to request an official build of 'mod_nss-1.0.8-16.el6' on RHEL 6.4 per the following bugs: * *Bugzilla Bug #769906* -mod_nss insists on Required value NSSCipherSuite not set. The official source tarball is located here: * http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz While the revised spec file is attached and ALL required patches and other files for RHEL 6.4 are located here: * http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-16.el6 Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mod_nss.spec Type: text/x-rpm-spec Size: 11226 bytes Desc: not available URL: From release-engineering at redhat.com Fri Oct 12 23:48:18 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Fri, 12 Oct 2012 19:48:18 -0400 Subject: [Pki-devel] [engineering.redhat.com #173037] Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: <5078AC3A.7060609@redhat.com> References: <5078AC3A.7060609@redhat.com> Message-ID: Ticket We would like to request an official build of 'mod_nss-1.0.8-16.el6' on RHEL 6.4 per the following bugs: * *Bugzilla Bug #769906* -mod_nss insists on Required value NSSCipherSuite not set. The official source tarball is located here: * http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz While the revised spec file is attached and ALL required patches and other files for RHEL 6.4 are located here: * http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-16.el6 Thanks, -- Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: mod_nss.spec Type: text/x-rpm-spec Size: 11226 bytes Desc: not available URL: From kwright at redhat.com Sun Oct 14 20:03:54 2012 From: kwright at redhat.com (Kevin Wright) Date: Sun, 14 Oct 2012 13:03:54 -0700 Subject: [Pki-devel] Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: <5078AC3A.7060609@redhat.com> References: <5078AC3A.7060609@redhat.com> Message-ID: On Oct 12, 2012, at 4:48 PM, Matthew Harmsen wrote: > We would like to request an official build of 'mod_nss-1.0.8-16.el6' on RHEL 6.4 per the following bugs: > Bugzilla Bug #769906 - mod_nss insists on Required value NSSCipherSuite not set. > The official source tarball is located here: > http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz > While the revised spec file is attached and ALL required patches and other files for RHEL 6.4 are located here: > http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-16.el6 > Thanks, > -- Matt > Hi Matt, The build is completed. You can go ahead and add it to the errata. Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4975125 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=238601 Thanks, --Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From release-engineering at redhat.com Sun Oct 14 20:04:05 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Sun, 14 Oct 2012 16:04:05 -0400 Subject: [Pki-devel] [engineering.redhat.com #173106] Re: Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: References: <5078AC3A.7060609@redhat.com> Message-ID: Ticket On Oct 12, 2012, at 4:48 PM, Matthew Harmsen wrote: > We would like to request an official build of 'mod_nss-1.0.8-16.el6' on RHEL 6.4 per the following bugs: > Bugzilla Bug #769906 - mod_nss insists on Required value NSSCipherSuite not set. > The official source tarball is located here: > http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz > While the revised spec file is attached and ALL required patches and other files for RHEL 6.4 are located here: > http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-16.el6 > Thanks, > -- Matt > Hi Matt, The build is completed. You can go ahead and add it to the errata. Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4975125 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=238601 Thanks, --Kevin From release-engineering at redhat.com Sun Oct 14 20:04:28 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Sun, 14 Oct 2012 16:04:28 -0400 Subject: [Pki-devel] [engineering.redhat.com #173037] Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: <5078AC3A.7060609@redhat.com> References: <5078AC3A.7060609@redhat.com> Message-ID: Ticket build completed: Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4975125 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=238601 From release-engineering at redhat.com Sun Oct 14 20:07:26 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Sun, 14 Oct 2012 16:07:26 -0400 Subject: [Pki-devel] [engineering.redhat.com #173106] Re: Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: References: <5078AC3A.7060609@redhat.com> Message-ID: Ticket this is a duplicate of: 173037 From mharmsen at redhat.com Mon Oct 15 00:20:14 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Sun, 14 Oct 2012 17:20:14 -0700 Subject: [Pki-devel] Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: References: <5078AC3A.7060609@redhat.com> Message-ID: <507B56BE.20109@redhat.com> Kevin Wright wrote: > > On Oct 12, 2012, at 4:48 PM, Matthew Harmsen wrote: > >> We would like to request an official build of 'mod_nss-1.0.8-16.el6' >> on RHEL 6.4 per the following bugs: >> >> * >> *Bugzilla Bug #769906* >> - mod_nss >> insists on Required value NSSCipherSuite not set. >> >> The official source tarball is located here: >> >> * http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz >> >> While the revised spec file is attached and ALL required patches and >> other files for RHEL 6.4 are located here: >> >> * http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-16.el6 >> >> Thanks, >> -- Matt >> > > Hi Matt, > > The build is completed. You can go ahead and add it to the errata. > > > Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4975125 > Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=238601 > > Thanks, > --Kevin Kevin, Added to errata. Thanks! -- Matt From release-engineering at redhat.com Mon Oct 15 00:20:20 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Sun, 14 Oct 2012 20:20:20 -0400 Subject: [Pki-devel] [engineering.redhat.com #173120] Re: Request to build 'mod_nss-1.0.8-16.el6' on RHEL 6.4 . . . In-Reply-To: <507B56BE.20109@redhat.com> References: <5078AC3A.7060609@redhat.com> <507B56BE.20109@redhat.com> Message-ID: Ticket Kevin Wright wrote: > > On Oct 12, 2012, at 4:48 PM, Matthew Harmsen wrote: > >> We would like to request an official build of 'mod_nss-1.0.8-16.el6' >> on RHEL 6.4 per the following bugs: >> >> * >> *Bugzilla Bug #769906* >> - mod_nss >> insists on Required value NSSCipherSuite not set. >> >> The official source tarball is located here: >> >> * http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz >> >> While the revised spec file is attached and ALL required patches and >> other files for RHEL 6.4 are located here: >> >> * http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-16.el6 >> >> Thanks, >> -- Matt >> > > Hi Matt, > > The build is completed. You can go ahead and add it to the errata. > > > Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4975125 > Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=238601 > > Thanks, > --Kevin Kevin, Added to errata. Thanks! -- Matt From edewata at redhat.com Tue Oct 16 18:58:16 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Oct 2012 13:58:16 -0500 Subject: [Pki-devel] [PATCH] 138 Enabled authentication for security domain REST interface. Message-ID: <507DAE48.1040702@redhat.com> The REST interface for security domain has been refactored and configured such that it requires authentication. A CLI has been added to get an installation token. Ticket #309 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0138-Enabled-authentication-for-security-domain-REST-inte.patch Type: text/x-patch Size: 34729 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 16 18:58:21 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 16 Oct 2012 13:58:21 -0500 Subject: [Pki-devel] [PATCH] 139 Refactored GetCookie servlet. Message-ID: <507DAE4D.9010406@redhat.com> The GetCookie servlet has been refactored to use the new SecurityDomainProcessor. Ticket #309 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0139-Refactored-GetCookie-servlet.patch Type: text/x-patch Size: 8022 bytes Desc: not available URL: From alee at redhat.com Thu Oct 18 03:07:28 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 17 Oct 2012 23:07:28 -0400 Subject: [Pki-devel] [PATCH] 73, 74 patches to get tps and ra to configure and start correctly Message-ID: <1350529649.19017.216.camel@aleeredhat.laptop> To get TPS running and configured, we need to: 1. Reorder http.conf to actually read worker config 2. Change functions so that the TPS would restart. Before restarts would fail because the tus link already exists 3. Modify system verification test to return correctly when tests are successful Patch 73 is for dogtag 10. Patch 74 is for dogtag 9. Please review. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0073-Fixes-to-get-TPS-to-configure-correctly.patch Type: text/x-patch Size: 5596 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0074-Changes-to-allow-tps-to-start-correctly.patch Type: text/x-patch Size: 3101 bytes Desc: not available URL: From edewata at redhat.com Thu Oct 18 04:06:09 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 17 Oct 2012 23:06:09 -0500 Subject: [Pki-devel] [PATCH] 138 Enabled authentication for security domain REST interface. In-Reply-To: <507DAE48.1040702@redhat.com> References: <507DAE48.1040702@redhat.com> Message-ID: <507F8031.6090707@redhat.com> On 10/16/2012 1:58 PM, Endi Sukma Dewata wrote: > The REST interface for security domain has been refactored and > configured such that it requires authentication. A CLI has been > added to get an installation token. > > Ticket #309 New patch attached. Restored the original way to get the client's IP address using InetAddress class instead off getRemoteAddr(). Tested installing IPA replica. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0138-1-Enabled-authentication-for-security-domain-REST-inte.patch Type: text/x-patch Size: 35372 bytes Desc: not available URL: From edewata at redhat.com Thu Oct 18 04:06:25 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 17 Oct 2012 23:06:25 -0500 Subject: [Pki-devel] [PATCH] 139 Refactored GetCookie servlet. In-Reply-To: <507DAE4D.9010406@redhat.com> References: <507DAE4D.9010406@redhat.com> Message-ID: <507F8041.5080603@redhat.com> On 10/16/2012 1:58 PM, Endi Sukma Dewata wrote: > The GetCookie servlet has been refactored to use the new > SecurityDomainProcessor. > > Ticket #309 Rebased on top of patch #138-1. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0139-1-Refactored-GetCookie-servlet.patch Type: text/x-patch Size: 7932 bytes Desc: not available URL: From alee at redhat.com Thu Oct 18 05:28:29 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 18 Oct 2012 01:28:29 -0400 Subject: [Pki-devel] [PATCH] 75 - Re-order VLV indexing when setting up database Message-ID: <1350538110.19017.220.camel@aleeredhat.laptop> When setting up a clone, the VLV indexes are added before the data is replicated. This results in errors in adding the VLV indexes because the entries that the VLV indexes depend on do not yet exist. This patch re-orders the sequence of operations. Tested with IPA cloning - errors no longer occur. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0075-Reorder-VLV-indexing-for-clones-to-avoid-errors.patch Type: text/x-patch Size: 2835 bytes Desc: not available URL: From alee at redhat.com Thu Oct 18 13:47:21 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 18 Oct 2012 09:47:21 -0400 Subject: [Pki-devel] [PATCH] 138 Enabled authentication for security domain REST interface. In-Reply-To: <507F8031.6090707@redhat.com> References: <507DAE48.1040702@redhat.com> <507F8031.6090707@redhat.com> Message-ID: <1350568042.19017.221.camel@aleeredhat.laptop> ack On Wed, 2012-10-17 at 23:06 -0500, Endi Sukma Dewata wrote: > On 10/16/2012 1:58 PM, Endi Sukma Dewata wrote: > > The REST interface for security domain has been refactored and > > configured such that it requires authentication. A CLI has been > > added to get an installation token. > > > > Ticket #309 > > New patch attached. Restored the original way to get the client's IP > address using InetAddress class instead off getRemoteAddr(). Tested > installing IPA replica. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Oct 18 13:47:45 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 18 Oct 2012 09:47:45 -0400 Subject: [Pki-devel] [PATCH] 139 Refactored GetCookie servlet. In-Reply-To: <507F8041.5080603@redhat.com> References: <507DAE4D.9010406@redhat.com> <507F8041.5080603@redhat.com> Message-ID: <1350568066.19017.222.camel@aleeredhat.laptop> ack On Wed, 2012-10-17 at 23:06 -0500, Endi Sukma Dewata wrote: > On 10/16/2012 1:58 PM, Endi Sukma Dewata wrote: > > The GetCookie servlet has been refactored to use the new > > SecurityDomainProcessor. > > > > Ticket #309 > > Rebased on top of patch #138-1. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Oct 18 15:08:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 18 Oct 2012 10:08:30 -0500 Subject: [Pki-devel] [PATCH] 138 Enabled authentication for security domain REST interface. In-Reply-To: <1350568042.19017.221.camel@aleeredhat.laptop> References: <507DAE48.1040702@redhat.com> <507F8031.6090707@redhat.com> <1350568042.19017.221.camel@aleeredhat.laptop> Message-ID: <50801B6E.5010702@redhat.com> On 10/18/2012 8:47 AM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Oct 18 15:08:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 18 Oct 2012 10:08:41 -0500 Subject: [Pki-devel] [PATCH] 139 Refactored GetCookie servlet. In-Reply-To: <1350568066.19017.222.camel@aleeredhat.laptop> References: <507DAE4D.9010406@redhat.com> <507F8041.5080603@redhat.com> <1350568066.19017.222.camel@aleeredhat.laptop> Message-ID: <50801B79.9070205@redhat.com> On 10/18/2012 8:47 AM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Oct 18 15:09:44 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 18 Oct 2012 10:09:44 -0500 Subject: [Pki-devel] [PATCH] 133 Added PKIConnection. In-Reply-To: <50743559.4040201@redhat.com> References: <50743559.4040201@redhat.com> Message-ID: <50801BB8.5000004@redhat.com> On 10/9/2012 9:31 AM, Endi Sukma Dewata wrote: > The code in PKIClient has been refactored into PKIConnection > such that a single connection object can be used by several > REST clients. The PKIClient will remain the base class for > all REST clients. > > Ticket #357 Rebased. Please apply in this order: 133-1, 134, 135-1, 136, 137. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0133-1-Added-PKIConnection.patch Type: text/x-patch Size: 34586 bytes Desc: not available URL: From edewata at redhat.com Thu Oct 18 15:10:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 18 Oct 2012 10:10:01 -0500 Subject: [Pki-devel] [PATCH] 135 Added REST account service. In-Reply-To: <50743563.4020807@redhat.com> References: <50743563.4020807@redhat.com> Message-ID: <50801BC9.9030502@redhat.com> On 10/9/2012 9:32 AM, Endi Sukma Dewata wrote: > A REST account service has been added to allow client to login > to establish a session and to logout to destroy the session. This > way multiple operations can be executed using the same session > without having to re-authenticate. > > Ticket #357 Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0135-1-Added-REST-account-service.patch Type: text/x-patch Size: 19582 bytes Desc: not available URL: From alee at redhat.com Thu Oct 18 21:32:58 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 18 Oct 2012 17:32:58 -0400 Subject: [Pki-devel] [PATCH] 73, 74 patches to get tps and ra to configure and start correctly In-Reply-To: <1350529649.19017.216.camel@aleeredhat.laptop> References: <1350529649.19017.216.camel@aleeredhat.laptop> Message-ID: <1350595979.12636.8.camel@aleeredhat.laptop> acked by Endi. Pushed to master and d9 On Wed, 2012-10-17 at 23:07 -0400, Ade Lee wrote: > To get TPS running and configured, we need to: > > 1. Reorder http.conf to actually read worker config > 2. Change functions so that the TPS would restart. Before restarts > would fail because the tus link already exists > 3. Modify system verification test to return correctly when tests > are successful > > Patch 73 is for dogtag 10. Patch 74 is for dogtag 9. > > Please review. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Oct 18 21:44:10 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 18 Oct 2012 16:44:10 -0500 Subject: [Pki-devel] [PATCH] 125 Fixed synchronization problem in CertificateRepository. In-Reply-To: <1349102645.2575.102.camel@aleeredhat.laptop> References: <50627274.7010304@redhat.com> <5065E9F6.70006@redhat.com> <5069A409.6020301@redhat.com> <1349102645.2575.102.camel@aleeredhat.laptop> Message-ID: <5080782A.1060109@redhat.com> On 10/1/2012 9:44 AM, Ade Lee wrote: >> Just to clarify the IRC discussion last week, this patch is supposed to >> address the long blocking issue by reverting to Dogtag 9 behavior, >> assuming the Dogtag 9 has the correct behavior. >> >> In Dogtag 9 the processRevokedCerts() exists in CRLIssuingPoint class as >> shown in this simplified code: >> >> public void processRevokedCerts(IElementProcessor p) { >> >> // NOTE: dangerous cast. >> // correct way would be to modify interface and add >> // accessor but we don't want to touch the interface >> >> CertificateRepository cr = (CertificateRepository)mCertRepository; >> >> synchronized (cr.mCertStatusUpdateThread) { >> CMS.debug("Starting processRevokedCerts (entered lock)"); >> >> list = mCertRepository.findCertRecordsInList(...); >> list.processCertRecords(...); >> >> CMS.debug("processRevokedCerts done"); >> } >> } >> >> There are some issues in the above code: >> >> 1. In Dogtag 9 the mCertRepository is being downcasted to >> CertificateRepository. As indicated by the comment in the code this is >> dangerous and we are supposed to modify the ICertificateRepository >> interface. In Dogtag 10 this was fixed by adding a new method called >> processRevokedCerts() into the interface so it's no longer necessary to >> downcast mCertRepository. The above code will now look like this: >> >> public void processRevokedCerts(IElementProcessor p) { >> mCertRepository.processRevokedCerts(...); >> } >> >> 2. In Dogtag 9 the code locks the mCertStatusUpdateThread which is an >> attribute of the mCertRepository. This is not a good OO practice because >> it's breaking the encapsulation. We could add a method >> getCertStatusUpdateThread() but it's still not a good solution because >> the thread class is a private class of CertificateRepository. The >> CRLIssuingPoint isn't supposed to see the thread object. This patch >> addresses this issue by moving the above code into >> CertificateRepository's processRevokedCerts(). This way the certificate >> repository can lock its own thread without breaking encapsulation. >> >> public void processRevokedCerts(IElementProcessor p) { >> synchronized (mCertStatusUpdateThread) { >> CMS.debug("Starting processRevokedCerts (entered lock)"); >> >> list = this.findCertRecordsInList(...); >> list.processCertRecords(...); >> >> CMS.debug("processRevokedCerts done"); >> } >> } >> >> This, however, is not the final code. See the following point. >> >> 3. In Dogtag 9 the locking is done using a synchronized block. While it >> works just fine, the code could be implemented with a synchronized >> method which would be cleaner: the object being locked is implicit, and >> here we block the whole method which has a well defined boundary, >> instead of a piece of code in the middle of a method. >> > I agree with points 1 and 2. It makes sense to have > processCertRecords() as a method within CertificateRepository, so that > it can lock its own private thread. I would be OK with the code in > point 2 above. > > I'm not sure I agree that locking using a synchronized method is any > cleaner though. The patch moves code which does not is not executed by > the maintenance thread into the maintenance thread, purely for the sake > of elucidating synchronization. The maintenance thread should contain > only the methods that it executes. New patch attached. As discussed, this patch will now revert the code structure to be similar to the one in the Dogtag 9, meaning the point #1 and #2 above will also be reverted. I hope this is sufficient to address the synchronization issue in ticket #313. Further clean up can be done separately. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0125-1-Fixed-synchronization-problem-in-CertificateReposito.patch Type: text/x-patch Size: 11117 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 19 18:02:36 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 19 Oct 2012 13:02:36 -0500 Subject: [Pki-devel] [PATCH] 140 Fixed error handling in RetrieveModificationsTask. Message-ID: <508195BC.9010102@redhat.com> The RetrieveModificationsTask has been modified such that it can recover from errors while still allowing graceful shutdown. The task is scheduled to run once. When it's done it will schecule another one depending on the situation. If the search is abandoned or the connection is closed it will wait one minute before reconnecting. If the system is being shutdown it will not schedule any more task. Ticket #365 To test the patch: 1. Create CA. 2. Add the following parameter into CS.cfg: ca.listenToCloneModifications=true 3. Restart CA. 4. Watch the debug log. 5. Stop slapd, an exception will appear, then it will retry every 1 minute. 6. Start slapd again, the task will eventually continue. 7. Stop CA, it will show the task being shutdown. Note that it may miss modifications that happen during the 1-minute window between slapd startup and next task execution. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0140-Fixed-error-handling-in-RetrieveModificationsTask.patch Type: text/x-patch Size: 7281 bytes Desc: not available URL: From mharmsen at redhat.com Fri Oct 19 22:15:41 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 19 Oct 2012 15:15:41 -0700 Subject: [Pki-devel] Request to build pki-core-9.0.3-27.el6 for RHEL 6.4 in Brew . . . Message-ID: <5081D10D.4000202@redhat.com> We would like to request an official build of 'pki-core-9.0.3-27.el6' for RHEL 6.4 in Brew to resolve the following bugs: * *Bugzilla Bug #867640* -ipa-replica-install Configuration of CA failed The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * pki-core-9.0.3-bz771790.patch * pki-core-9.0.3-bz745677.patch * pki-core-9.0.3-bz769388.patch * pki-core-9.0.3-bz802396.patch * pki-core-9.0.3-bz819111.patch * pki-core-9.0.3-bz841663.patch * pki-core-9.0.3-bz844459.patch * pki-core-9.0.3-bz858864.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 46468 bytes Desc: not available URL: From release-engineering at redhat.com Fri Oct 19 22:15:49 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Fri, 19 Oct 2012 18:15:49 -0400 Subject: [Pki-devel] [engineering.redhat.com #174055] Request to build pki-core-9.0.3-27.el6 for RHEL 6.4 in Brew . . . In-Reply-To: <5081D10D.4000202@redhat.com> References: <5081D10D.4000202@redhat.com> Message-ID: Ticket We would like to request an official build of 'pki-core-9.0.3-27.el6' for RHEL 6.4 in Brew to resolve the following bugs: * *Bugzilla Bug #867640* -ipa-replica-install Configuration of CA failed The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * pki-core-9.0.3-bz771790.patch * pki-core-9.0.3-bz745677.patch * pki-core-9.0.3-bz769388.patch * pki-core-9.0.3-bz802396.patch * pki-core-9.0.3-bz819111.patch * pki-core-9.0.3-bz841663.patch * pki-core-9.0.3-bz844459.patch * pki-core-9.0.3-bz858864.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 46468 bytes Desc: not available URL: From release-engineering at redhat.com Fri Oct 19 22:34:14 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Fri, 19 Oct 2012 18:34:14 -0400 Subject: [Pki-devel] [engineering.redhat.com #174055] Request to build pki-core-9.0.3-27.el6 for RHEL 6.4 in Brew . . . References: Message-ID: Ticket build complted. closing. From mharmsen at redhat.com Sat Oct 20 02:21:07 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 19 Oct 2012 19:21:07 -0700 Subject: [Pki-devel] Request to build 'mod_nss-1.0.8-17.el6' on RHEL 6.4 . . . Message-ID: <50820A93.3020504@redhat.com> We would like to request an official build of 'mod_nss-1.0.8-17.el6' on RHEL 6.4 per the following bugs: * *Bugzilla Bug #816394* -[RFE] Provide Apache 2.2 support for TLS v1.1 via NSS through mod_nss . . . The official source tarball is located here: * http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz While the revised spec file is attached and ALL required patches and other files for RHEL 6.4 are located here: * http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-17.el6 Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mod_nss.spec Type: text/x-rpm-spec Size: 11539 bytes Desc: not available URL: From release-engineering at redhat.com Sat Oct 20 02:21:14 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Fri, 19 Oct 2012 22:21:14 -0400 Subject: [Pki-devel] [engineering.redhat.com #174059] Request to build 'mod_nss-1.0.8-17.el6' on RHEL 6.4 . . . In-Reply-To: <50820A93.3020504@redhat.com> References: <50820A93.3020504@redhat.com> Message-ID: Ticket We would like to request an official build of 'mod_nss-1.0.8-17.el6' on RHEL 6.4 per the following bugs: * *Bugzilla Bug #816394* -[RFE] Provide Apache 2.2 support for TLS v1.1 via NSS through mod_nss . . . The official source tarball is located here: * http://directory.fedoraproject.org/sources/mod_nss-1.0.8.tar.gz While the revised spec file is attached and ALL required patches and other files for RHEL 6.4 are located here: * http://pki.fedoraproject.org/pki/sources/mod_nss/mod_nss-1.0.8-17.el6 Thanks, -- Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: mod_nss.spec Type: text/x-rpm-spec Size: 11539 bytes Desc: not available URL: From release-engineering at redhat.com Sun Oct 21 05:39:25 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Sun, 21 Oct 2012 01:39:25 -0400 Subject: [Pki-devel] [engineering.redhat.com #174059] Request to build 'mod_nss-1.0.8-17.el6' on RHEL 6.4 . . . References: Message-ID: Ticket build complted. closing. From alee at redhat.com Mon Oct 22 03:24:56 2012 From: alee at redhat.com (Ade Lee) Date: Sun, 21 Oct 2012 23:24:56 -0400 Subject: [Pki-devel] [PATCH] 76 - Reorder-VLV-indexing-for-clones-to-avoid-errors Message-ID: <1350876296.12636.16.camel@aleeredhat.laptop> Revised patch 75. Please ignore that patch. When setting up a clone, the VLV indexes are added before the data is replicated. This results in errors in adding the VLV indexes because the entries that the VLV indexes depend on do not yet exist. This patch re-orders the sequence of operations. Specifically, index operations occur before the data is replicated so that the indexes are populated, whereas VLV indexes are populated afterwards. In the case of VLV indexes, a VLV indexing task is scheduled and executed. Tested with IPA cloning - errors no longer occur. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0076-Reorder-VLV-indexing-for-clones-to-avoid-errors.patch Type: text/x-patch Size: 6974 bytes Desc: not available URL: From alee at redhat.com Mon Oct 22 03:38:27 2012 From: alee at redhat.com (Ade Lee) Date: Sun, 21 Oct 2012 23:38:27 -0400 Subject: [Pki-devel] PATCH - 77 - Provide-option-to-install-rather-than-replicate-schema Message-ID: <1350877107.12636.29.camel@aleeredhat.laptop> This patch addresses a couple of issues found in IPA integration, specifically the replication of data from an unmerged IPA instance to a merged one. The scenario will be described in detail in a separate email. Please review, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0077-Provide-option-to-install-rather-than-replicate-sche.patch Type: text/x-patch Size: 12146 bytes Desc: not available URL: From alee at redhat.com Mon Oct 22 04:13:41 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 00:13:41 -0400 Subject: [Pki-devel] PATCH - 77 - Provide-option-to-install-rather-than-replicate-schema In-Reply-To: <1350877107.12636.29.camel@aleeredhat.laptop> References: <1350877107.12636.29.camel@aleeredhat.laptop> Message-ID: <1350879222.12636.56.camel@aleeredhat.laptop> slight change to previous patch. Added new field in ConfigurationRequest to toString(). On Sun, 2012-10-21 at 23:38 -0400, Ade Lee wrote: > This patch addresses a couple of issues found in IPA integration, > specifically the replication of data from an unmerged IPA instance to a > merged one. > > The scenario will be described in detail in a separate email. > > Please review, > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0077-1-Provide-option-to-install-rather-than-replicate-sche.patch Type: text/x-patch Size: 12591 bytes Desc: not available URL: From alee at redhat.com Mon Oct 22 16:13:19 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 12:13:19 -0400 Subject: [Pki-devel] PATCH - 77 - Provide-option-to-install-rather-than-replicate-schema In-Reply-To: <1350879222.12636.56.camel@aleeredhat.laptop> References: <1350877107.12636.29.camel@aleeredhat.laptop> <1350879222.12636.56.camel@aleeredhat.laptop> Message-ID: <1350922399.11698.4.camel@aleeredhat.laptop> Acked by Endi. pushed to master. On Mon, 2012-10-22 at 00:13 -0400, Ade Lee wrote: > slight change to previous patch. Added new field in > ConfigurationRequest to toString(). > > On Sun, 2012-10-21 at 23:38 -0400, Ade Lee wrote: > > This patch addresses a couple of issues found in IPA integration, > > specifically the replication of data from an unmerged IPA instance to a > > merged one. > > > > The scenario will be described in detail in a separate email. > > > > Please review, > > Ade > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 22 16:13:43 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 12:13:43 -0400 Subject: [Pki-devel] [PATCH] 76 - Reorder-VLV-indexing-for-clones-to-avoid-errors In-Reply-To: <1350876296.12636.16.camel@aleeredhat.laptop> References: <1350876296.12636.16.camel@aleeredhat.laptop> Message-ID: <1350922423.11698.5.camel@aleeredhat.laptop> Acked by Endi. Pushed to master. On Sun, 2012-10-21 at 23:24 -0400, Ade Lee wrote: > Revised patch 75. Please ignore that patch. > > When setting up a clone, the VLV indexes are added before the data is > replicated. This results in errors in adding the VLV indexes because > the entries that the VLV indexes depend on do not yet exist. > > This patch re-orders the sequence of operations. Specifically, index > operations occur before the data is replicated so that the indexes are > populated, whereas VLV indexes are populated afterwards. In the case of > VLV indexes, a VLV indexing task is scheduled and executed. > > Tested with IPA cloning - errors no longer occur. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 22 17:58:54 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 13:58:54 -0400 Subject: [Pki-devel] [PATCH] 133 Added PKIConnection. In-Reply-To: <50801BB8.5000004@redhat.com> References: <50743559.4040201@redhat.com> <50801BB8.5000004@redhat.com> Message-ID: <1350928734.11698.8.camel@aleeredhat.laptop> ack On Thu, 2012-10-18 at 10:09 -0500, Endi Sukma Dewata wrote: > On 10/9/2012 9:31 AM, Endi Sukma Dewata wrote: > > The code in PKIClient has been refactored into PKIConnection > > such that a single connection object can be used by several > > REST clients. The PKIClient will remain the base class for > > all REST clients. > > > > Ticket #357 > > Rebased. Please apply in this order: 133-1, 134, 135-1, 136, 137. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 22 17:59:09 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 13:59:09 -0400 Subject: [Pki-devel] [PATCH] 135 Added REST account service. In-Reply-To: <50801BC9.9030502@redhat.com> References: <50743563.4020807@redhat.com> <50801BC9.9030502@redhat.com> Message-ID: <1350928749.11698.9.camel@aleeredhat.laptop> ack On Thu, 2012-10-18 at 10:10 -0500, Endi Sukma Dewata wrote: > On 10/9/2012 9:32 AM, Endi Sukma Dewata wrote: > > A REST account service has been added to allow client to login > > to establish a session and to logout to destroy the session. This > > way multiple operations can be executed using the same session > > without having to re-authenticate. > > > > Ticket #357 > > Rebased. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 22 18:00:20 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 14:00:20 -0400 Subject: [Pki-devel] [PATCH] 134 Added PKIPrincipal. In-Reply-To: <5074355E.2000703@redhat.com> References: <5074355E.2000703@redhat.com> Message-ID: <1350928828.11698.10.camel@aleeredhat.laptop> ack On Tue, 2012-10-09 at 09:31 -0500, Endi Sukma Dewata wrote: > Previously in PKIRealm the authentication token was stored in a thread > local variable. This does not work for multiple operations executed > using the same session because each operation may be handled by > different threads. A new PKIPrincipal has been added to store the > authentication token so that the threads can get the correct token > for the session. > > Ticket #357 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 22 18:00:39 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 14:00:39 -0400 Subject: [Pki-devel] [PATCH] 136 Enabled realm authentication for certificate requests. In-Reply-To: <50749056.4080001@redhat.com> References: <50749056.4080001@redhat.com> Message-ID: <1350928845.11698.11.camel@aleeredhat.laptop> ack On Tue, 2012-10-09 at 16:00 -0500, Endi Sukma Dewata wrote: > The realm authentication on certificate request REST services has > been enabled. Since now in the CLI the authentication is done using > a separate login operation, it is now possible to POST the approval > data without the problem related to chunked message. > > Ticket #300 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Oct 22 18:00:56 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 22 Oct 2012 14:00:56 -0400 Subject: [Pki-devel] [PATCH] 137 Fixed KRA test. In-Reply-To: <5074CBE8.5080405@redhat.com> References: <5074CBE8.5080405@redhat.com> Message-ID: <1350928857.11698.12.camel@aleeredhat.laptop> ack On Tue, 2012-10-09 at 20:14 -0500, Endi Sukma Dewata wrote: > The security configuration, JAXB mappings, and test script for KRA > have been updated to run properly. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Mon Oct 22 21:54:36 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 22 Oct 2012 17:54:36 -0400 (EDT) Subject: [Pki-devel] Review Request In-Reply-To: <939142131.18834779.1350942687924.JavaMail.root@redhat.com> Message-ID: <799082582.18835466.1350942876268.JavaMail.root@redhat.com> Request review for issue: Bug 864607 - Empty certificate search in TPS results in httpd.worker segmentation fault then server error. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=864607 Attachment: https://bugzilla.redhat.com/attachment.cgi?id=630239&action=diff From edewata at redhat.com Mon Oct 22 22:07:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 22 Oct 2012 17:07:30 -0500 Subject: [Pki-devel] [PATCH] 130 Enabled Tomcat security manager. In-Reply-To: <506CC3D0.10806@redhat.com> References: <506CC3D0.10806@redhat.com> Message-ID: <5085C3A2.4040001@redhat.com> On 10/3/2012 6:01 PM, Endi Sukma Dewata wrote: > The tomcat.conf and pkideployment.cfg have been modified to enable > the security manager. The catalina.policy has been updated with > more specific permissions for PKI. > > Ticket #223 New patch attached. It will now combine the default Tomcat policy with PKI standard policy and custom policy. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0130-2-Enabled-Tomcat-security-manager.patch Type: text/x-patch Size: 21950 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 23 14:35:29 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 09:35:29 -0500 Subject: [Pki-devel] [PATCH] 135 Added REST account service. In-Reply-To: <1350928749.11698.9.camel@aleeredhat.laptop> References: <50743563.4020807@redhat.com> <50801BC9.9030502@redhat.com> <1350928749.11698.9.camel@aleeredhat.laptop> Message-ID: <5086AB31.3050309@redhat.com> On 10/22/2012 12:59 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Oct 23 14:35:33 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 09:35:33 -0500 Subject: [Pki-devel] [PATCH] 136 Enabled realm authentication for certificate requests. In-Reply-To: <1350928845.11698.11.camel@aleeredhat.laptop> References: <50749056.4080001@redhat.com> <1350928845.11698.11.camel@aleeredhat.laptop> Message-ID: <5086AB35.4030604@redhat.com> On 10/22/2012 1:00 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Oct 23 14:35:37 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 09:35:37 -0500 Subject: [Pki-devel] [PATCH] 137 Fixed KRA test. In-Reply-To: <1350928857.11698.12.camel@aleeredhat.laptop> References: <5074CBE8.5080405@redhat.com> <1350928857.11698.12.camel@aleeredhat.laptop> Message-ID: <5086AB39.2000507@redhat.com> On 10/22/2012 1:00 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From cfu at redhat.com Tue Oct 23 16:53:33 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 23 Oct 2012 09:53:33 -0700 Subject: [Pki-devel] Review Request In-Reply-To: <799082582.18835466.1350942876268.JavaMail.root@redhat.com> References: <799082582.18835466.1350942876268.JavaMail.root@redhat.com> Message-ID: <5086CB8D.3050708@redhat.com> The following are my review comments: - I see you replaced the PL_strcat() calls in mod_tokendb.cpp. How about the other PL_strcat() calls in other files? Do they not present any issue? - The following RA::Debug() message and comment seems a bit confusing for me as it seems to declare that it's about to truncate and yet it's actually trying to resize: A::Debug( "safe_injection_strcat, about to truncate, resize injection buffer: ", "current len: %d expected_len %d data_len: %d cur_injection_size %d",current_len, expected_len, cat_data_len, *injection_size ); /* We are going to get truncated! How about say something like "...resizing to avoid truncation..." - safe_injection_strcat() not sure of the role of the variable "result" as it only gets set once at the end, but returned many times in the middle. Unclear if 1 is success or 0 is. There is no comment (yeah, could you please provide comment for parameters and return value?). It is especially confusing when check_injection_size() comment says "returns 0 on success, 1 on failure" and yet safe_injection_strcat() has "if (check_res == 1), return result", where result was init'd to be 0, So does that mean it is the opposite of the check_injection_size()? Another thing is the callers ignore the return values from safe_injection_strcat() anyway, so why return anything at all? - Why only call check_injection_size 2nd time if still not enough? Christina On 10/22/2012 02:54 PM, John Magne wrote: > Request review for issue: > > > Bug 864607 - Empty certificate search in TPS results in httpd.worker segmentation fault then server error. > > Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=864607 > > Attachment: > > https://bugzilla.redhat.com/attachment.cgi?id=630239&action=diff > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Oct 23 17:22:12 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 23 Oct 2012 13:22:12 -0400 Subject: [Pki-devel] [PATCH] 78 changes to remove pki-selinux from the build. Message-ID: <1351012932.26587.2.camel@aleeredhat.laptop> Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0078-changes-to-remove-pki-selinux-from-f18-build.patch Type: text/x-patch Size: 8825 bytes Desc: not available URL: From jmagne at redhat.com Tue Oct 23 17:42:04 2012 From: jmagne at redhat.com (John Magne) Date: Tue, 23 Oct 2012 13:42:04 -0400 (EDT) Subject: [Pki-devel] Review Request In-Reply-To: <5086CB8D.3050708@redhat.com> Message-ID: <1336369990.19263429.1351014124299.JavaMail.root@redhat.com> Christina, thanks for the review, comments below: ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, October 23, 2012 9:53:33 AM Subject: Re: [Pki-devel] Review Request The following are my review comments: - I see you replaced the PL_strcat() calls in mod_tokendb.cpp. How about the other PL_strcat() calls in other files? Do they not present any issue? Jack: This particular problem was isolated to mod_tokendb.cpp. It made sense to concentrate on the specific problem this round and deal with the rest later. - The following RA::Debug() message and comment seems a bit confusing for me as it seems to declare that it's about to truncate and yet it's actually trying to resize: A::Debug( "safe_injection_strcat, about to truncate, resize injection buffer: ", "current len: %d expected_len %d data_len: %d cur_injection_size %d",current_len, expected_len, cat_data_len, *injection_size ); /* We are going to get truncated! How about say something like "...resizing to avoid truncation..." - safe_injection_strcat() Jack: Will take care of it, thanks. not sure of the role of the variable "result" as it only gets set once at the end, but returned many times in the middle. Unclear if 1 is success or 0 is. There is no comment (yeah, could you please provide comment for parameters and return value?). It is especially confusing when check_injection_size() comment says "returns 0 on success, 1 on failure" and yet safe_injection_strcat() has "if (check_res == 1), return result", where result was init'd to be 0, So does that mean it is the opposite of the check_injection_size()? Another thing is the callers ignore the return values from safe_injection_strcat() anyway, so why return anything at all? Jack: Good catch, there is not much we can do if this routine fails. Also, the worst result now is truncation. - Why only call check_injection_size 2nd time if still not enough? Jack: This was done for safety, there is a small chance that the first realloc would not cover the data being added. It seemed prudent to try one more time in such a rare case. In case it fails, truncation would be the only bad result. Christina On 10/22/2012 02:54 PM, John Magne wrote: > Request review for issue: > > > Bug 864607 - Empty certificate search in TPS results in httpd.worker segmentation fault then server error. > > Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=864607 > > Attachment: > > https://bugzilla.redhat.com/attachment.cgi?id=630239&action=diff > > _______________________________________________ > 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 Tue Oct 23 19:27:42 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 14:27:42 -0500 Subject: [Pki-devel] [PATCH] 141 Added conditions for security domain REST service. Message-ID: <5086EFAE.9080606@redhat.com> The CertificateAuthorityApplication has been modified to deploy the REST service for security domain only if the server has been configured with a new security domain. Ticket #309 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0141-Added-conditions-for-security-domain-REST-service.patch Type: text/x-patch Size: 2194 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 23 20:29:27 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 15:29:27 -0500 Subject: [Pki-devel] [PATCH] 140 Fixed error handling in RetrieveModificationsTask. In-Reply-To: <508195BC.9010102@redhat.com> References: <508195BC.9010102@redhat.com> Message-ID: <5086FE27.9070909@redhat.com> On 10/19/2012 1:02 PM, Endi Sukma Dewata wrote: > The RetrieveModificationsTask has been modified such that it can > recover from errors while still allowing graceful shutdown. > > The task is scheduled to run once. When it's done it will schecule > another one depending on the situation. If the search is abandoned > or the connection is closed it will wait one minute before > reconnecting. If the system is being shutdown it will not > schedule any more task. > > Ticket #365 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Oct 23 20:29:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 15:29:30 -0500 Subject: [Pki-devel] [PATCH] 141 Added conditions for security domain REST service. In-Reply-To: <5086EFAE.9080606@redhat.com> References: <5086EFAE.9080606@redhat.com> Message-ID: <5086FE2A.6020709@redhat.com> On 10/23/2012 2:27 PM, Endi Sukma Dewata wrote: > The CertificateAuthorityApplication has been modified to deploy > the REST service for security domain only if the server has been > configured with a new security domain. > > Ticket #309 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Oct 23 20:32:54 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 15:32:54 -0500 Subject: [Pki-devel] [PATCH] 133 Added PKIConnection. In-Reply-To: <1350928734.11698.8.camel@aleeredhat.laptop> References: <50743559.4040201@redhat.com> <50801BB8.5000004@redhat.com> <1350928734.11698.8.camel@aleeredhat.laptop> Message-ID: <5086FEF6.9060404@redhat.com> On 10/22/2012 12:58 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Oct 23 20:32:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 15:32:57 -0500 Subject: [Pki-devel] [PATCH] 134 Added PKIPrincipal. In-Reply-To: <1350928828.11698.10.camel@aleeredhat.laptop> References: <5074355E.2000703@redhat.com> <1350928828.11698.10.camel@aleeredhat.laptop> Message-ID: <5086FEF9.1000601@redhat.com> On 10/22/2012 1:00 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From jmagne at redhat.com Tue Oct 23 20:47:51 2012 From: jmagne at redhat.com (John Magne) Date: Tue, 23 Oct 2012 16:47:51 -0400 (EDT) Subject: [Pki-devel] Review Request In-Reply-To: <5086CB8D.3050708@redhat.com> Message-ID: <1595101625.19318330.1351025271044.JavaMail.root@redhat.com> Portion of patch, to address cfu's issues: cfu, please review. https://bugzilla.redhat.com/attachment.cgi?id=632378&action=edit ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, October 23, 2012 9:53:33 AM Subject: Re: [Pki-devel] Review Request The following are my review comments: - I see you replaced the PL_strcat() calls in mod_tokendb.cpp. How about the other PL_strcat() calls in other files? Do they not present any issue? - The following RA::Debug() message and comment seems a bit confusing for me as it seems to declare that it's about to truncate and yet it's actually trying to resize: A::Debug( "safe_injection_strcat, about to truncate, resize injection buffer: ", "current len: %d expected_len %d data_len: %d cur_injection_size %d",current_len, expected_len, cat_data_len, *injection_size ); /* We are going to get truncated! How about say something like "...resizing to avoid truncation..." - safe_injection_strcat() not sure of the role of the variable "result" as it only gets set once at the end, but returned many times in the middle. Unclear if 1 is success or 0 is. There is no comment (yeah, could you please provide comment for parameters and return value?). It is especially confusing when check_injection_size() comment says "returns 0 on success, 1 on failure" and yet safe_injection_strcat() has "if (check_res == 1), return result", where result was init'd to be 0, So does that mean it is the opposite of the check_injection_size()? Another thing is the callers ignore the return values from safe_injection_strcat() anyway, so why return anything at all? - Why only call check_injection_size 2nd time if still not enough? Christina On 10/22/2012 02:54 PM, John Magne wrote: > Request review for issue: > > > Bug 864607 - Empty certificate search in TPS results in httpd.worker segmentation fault then server error. > > Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=864607 > > Attachment: > > https://bugzilla.redhat.com/attachment.cgi?id=630239&action=diff > > _______________________________________________ > 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 Tue Oct 23 21:02:05 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 16:02:05 -0500 Subject: [Pki-devel] [PATCH] 142 Added REST interface to get domain info. Message-ID: <508705CD.4050101@redhat.com> The REST interface for security domain has been updated to provide a method to get the domain info. A CLI has been provided to access this method. Ticket #309 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0142-Added-REST-interface-to-get-domain-info.patch Type: text/x-patch Size: 46173 bytes Desc: not available URL: From edewata at redhat.com Tue Oct 23 21:02:10 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 23 Oct 2012 16:02:10 -0500 Subject: [Pki-devel] [PATCH] 143 Refactored GetDomainXML servlet. Message-ID: <508705D2.7090206@redhat.com> The GetDomainXML servlet has been refactored to use the new SecurityDomainProcessor. Ticket #309 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0143-Refactored-GetDomainXML-servlet.patch Type: text/x-patch Size: 8311 bytes Desc: not available URL: From cfu at redhat.com Tue Oct 23 22:43:57 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 23 Oct 2012 15:43:57 -0700 Subject: [Pki-devel] Review Request In-Reply-To: <1595101625.19318330.1351025271044.JavaMail.root@redhat.com> References: <1595101625.19318330.1351025271044.JavaMail.root@redhat.com> Message-ID: <50871DAD.9040800@redhat.com> Jack, you might have missed this, but could you please give description to each parameter to safe_injection_strcat() in the comment at top? For comment style, there are some examples in the same file, such as get_post_field(). conditional ACK. thanks! Christina On 10/23/2012 01:47 PM, John Magne wrote: > Portion of patch, to address cfu's issues: > > cfu, please review. > > https://bugzilla.redhat.com/attachment.cgi?id=632378&action=edit > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, October 23, 2012 9:53:33 AM > Subject: Re: [Pki-devel] Review Request > > The following are my review comments: > > - I see you replaced the PL_strcat() calls in mod_tokendb.cpp. How > about the other PL_strcat() calls in other files? Do they not present > any issue? > > - The following RA::Debug() message and comment seems a bit confusing > for me as it seems to declare that it's about to truncate and yet it's > actually trying to resize: > > A::Debug( "safe_injection_strcat, about to truncate, resize injection > buffer: ", "current len: %d expected_len %d data_len: %d > cur_injection_size %d",current_len, expected_len, cat_data_len, > *injection_size ); > /* We are going to get truncated! > > How about say something like "...resizing to avoid truncation..." > > - safe_injection_strcat() > not sure of the role of the variable "result" as it only gets set once > at the end, but returned many times in the middle. Unclear if 1 is > success or 0 is. There is no comment (yeah, could you please provide > comment for parameters and return value?). It is especially confusing > when check_injection_size() comment says "returns 0 on success, 1 on > failure" and yet safe_injection_strcat() has "if (check_res == 1), > return result", where result was init'd to be 0, So does that mean it > is the opposite of the check_injection_size()? > Another thing is the callers ignore the return values from > safe_injection_strcat() anyway, so why return anything at all? > > - Why only call check_injection_size 2nd time if still not enough? > > Christina > > On 10/22/2012 02:54 PM, John Magne wrote: >> Request review for issue: >> >> >> Bug 864607 - Empty certificate search in TPS results in httpd.worker segmentation fault then server error. >> >> Bugzilla: >> https://bugzilla.redhat.com/show_bug.cgi?id=864607 >> >> Attachment: >> >> https://bugzilla.redhat.com/attachment.cgi?id=630239&action=diff >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Oct 24 13:38:55 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 24 Oct 2012 09:38:55 -0400 Subject: [Pki-devel] [PATCH] 78 changes to remove pki-selinux from the build. In-Reply-To: <1351012932.26587.2.camel@aleeredhat.laptop> References: <1351012932.26587.2.camel@aleeredhat.laptop> Message-ID: <1351085936.26587.10.camel@aleeredhat.laptop> acked by Endi. Pushed to master. On Tue, 2012-10-23 at 13:22 -0400, Ade Lee wrote: > Please review. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From rcritten at redhat.com Wed Oct 24 20:02:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Oct 2012 16:02:53 -0400 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: References: Message-ID: <5088496D.1070309@redhat.com> I assume he'd have to modify a profile to do this? rob -------------- next part -------------- An embedded message was scrubbed... From: George Machitidze Subject: [Freeipa-users] SHA-1 certificate support Date: Wed, 24 Oct 2012 14:51:30 +0400 Size: 4386 URL: From nalin at redhat.com Wed Oct 24 20:38:36 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 24 Oct 2012 16:38:36 -0400 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: <5088496D.1070309@redhat.com> References: <5088496D.1070309@redhat.com> Message-ID: <20121024203836.GB29052@redhat.com> On Wed, Oct 24, 2012 at 04:02:53PM -0400, Rob Crittenden wrote: > I assume he'd have to modify a profile to do this? There are two signatures when you're talking about using a CSR to request a certificate from an external CA. There's the digest used for the signature that the issuer includes in the certificate. In Dogtag, I believe that the allowed types are enumerated (by a signingAlgConstraint) in the profile, and the default is specified (as "ca.signing.defaultSigningAlgorithm") in the CA's CS.cfg file. Someone please correct me if I'm looking at the wrong places there. Then there's the digest used for the self-signature that the client includes in the CSR. The IPA installs script uses certutil, and it looks like certutil uses SHA1 by default. That's fine for this user, but I'll note that we can apparently use certutil's (undocumented?) -Z flag to switch that to something like SHA256. HTH, Nalin From cfu at redhat.com Wed Oct 24 20:46:19 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 24 Oct 2012 13:46:19 -0700 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: <5088496D.1070309@redhat.com> References: <5088496D.1070309@redhat.com> Message-ID: <5088539B.2090902@redhat.com> Is the question on how to sign a CSR with SHA1 signing algorithm? You select that with whatever tool you use to generate the CSR. Or, is the question on how to get the CA to sign your certificate with a SHA1 signing algorithm? In that case, you will have to find out from this "external CA" on how to do it. With Dogtag/RHCS, you will have to modify the profile as well as the CS.cfg (ca.signing.defaultSigningAlgorithm). Christina On 10/24/2012 01:02 PM, Rob Crittenden wrote: > I assume he'd have to modify a profile to do this? > > rob > > > _______________________________________________ > 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 awnuk at redhat.com Wed Oct 24 21:09:07 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 24 Oct 2012 14:09:07 -0700 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: <20121024203836.GB29052@redhat.com> References: <5088496D.1070309@redhat.com> <20121024203836.GB29052@redhat.com> Message-ID: <508858F3.2030304@redhat.com> On 10/24/2012 01:38 PM, Nalin Dahyabhai wrote: > On Wed, Oct 24, 2012 at 04:02:53PM -0400, Rob Crittenden wrote: >> I assume he'd have to modify a profile to do this? > There are two signatures when you're talking about using a CSR to > request a certificate from an external CA. > > There's the digest used for the signature that the issuer includes in > the certificate. In Dogtag, I believe that the allowed types are > enumerated (by a signingAlgConstraint) in the profile, and the default > is specified (as "ca.signing.defaultSigningAlgorithm") in the CA's > CS.cfg file. You can also specify default signing algorithm in the profile without changing CA's default signing algorithm. IPA's profile could but it does not specify default signing algorithm. See caIPAserviceCert.cfg: policyset.serverCertSet.8.default.params.signingAlg=- To specify default signing algorithm in the IPA profile, modify above line by including signing algorithm from the constraint list. See caIPAserviceCert.cfg: policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=. . . > > Someone please correct me if I'm looking at the wrong places there. > > Then there's the digest used for the self-signature that the client > includes in the CSR. The IPA installs script uses certutil, and it > looks like certutil uses SHA1 by default. That's fine for this user, > but I'll note that we can apparently use certutil's (undocumented?) -Z > flag to switch that to something like SHA256. > > HTH, > > Nalin > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From dhiva at es.net Wed Oct 24 21:31:19 2012 From: dhiva at es.net (Dhiva) Date: Wed, 24 Oct 2012 14:31:19 -0700 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: <508858F3.2030304@redhat.com> References: <5088496D.1070309@redhat.com> <20121024203836.GB29052@redhat.com> <508858F3.2030304@redhat.com> Message-ID: <50885E27.9040509@es.net> Does this also changes the value of "Subject Key Identifier" and "Auth Key Identifier" extensions? I am getting inconsistent results, but not sure if the algorithm should be same as the one used to sign the certificate. - dhiva On 10/24/12 2:09 PM, Andrew Wnuk wrote: > On 10/24/2012 01:38 PM, Nalin Dahyabhai wrote: >> On Wed, Oct 24, 2012 at 04:02:53PM -0400, Rob Crittenden wrote: >>> I assume he'd have to modify a profile to do this? >> There are two signatures when you're talking about using a CSR to >> request a certificate from an external CA. >> >> There's the digest used for the signature that the issuer includes in >> the certificate. In Dogtag, I believe that the allowed types are >> enumerated (by a signingAlgConstraint) in the profile, and the default >> is specified (as "ca.signing.defaultSigningAlgorithm") in the CA's >> CS.cfg file. > > You can also specify default signing algorithm in the profile without > changing CA's default signing algorithm. > > IPA's profile could but it does not specify default signing algorithm. > See caIPAserviceCert.cfg: > policyset.serverCertSet.8.default.params.signingAlg=- > > To specify default signing algorithm in the IPA profile, modify above > line by including signing algorithm from the constraint list. > See caIPAserviceCert.cfg: > policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=. . . > >> >> Someone please correct me if I'm looking at the wrong places there. >> >> Then there's the digest used for the self-signature that the client >> includes in the CSR. The IPA installs script uses certutil, and it >> looks like certutil uses SHA1 by default. That's fine for this user, >> but I'll note that we can apparently use certutil's (undocumented?) -Z >> flag to switch that to something like SHA256. >> >> HTH, >> >> Nalin >> >> _______________________________________________ >> 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 Thu Oct 25 03:30:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 24 Oct 2012 22:30:53 -0500 Subject: [Pki-devel] [PATCH] 144 Enabled account service for TKS and OCSP. Message-ID: <5088B26D.1030005@redhat.com> The REST account service has been added to TKS and OCSP to enable authentication. Ticket #375 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0144-Enabled-account-service-for-TKS-and-OCSP.patch Type: text/x-patch Size: 10523 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 25 14:07:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 25 Oct 2012 10:07:57 -0400 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: <20121024203836.GB29052@redhat.com> References: <5088496D.1070309@redhat.com> <20121024203836.GB29052@redhat.com> Message-ID: <508947BD.2080501@redhat.com> Nalin Dahyabhai wrote: > On Wed, Oct 24, 2012 at 04:02:53PM -0400, Rob Crittenden wrote: >> I assume he'd have to modify a profile to do this? > > There are two signatures when you're talking about using a CSR to > request a certificate from an external CA. > > There's the digest used for the signature that the issuer includes in > the certificate. In Dogtag, I believe that the allowed types are > enumerated (by a signingAlgConstraint) in the profile, and the default > is specified (as "ca.signing.defaultSigningAlgorithm") in the CA's > CS.cfg file. > > Someone please correct me if I'm looking at the wrong places there. > > Then there's the digest used for the self-signature that the client > includes in the CSR. The IPA installs script uses certutil, and it > looks like certutil uses SHA1 by default. That's fine for this user, > but I'll note that we can apparently use certutil's (undocumented?) -Z > flag to switch that to something like SHA256. The CSR is generated by dogtag. I'm not sure if it forks out to certutil or not but I'd suspect it doesn't. Can someone from the CS team confirm that changing the defaultSigningAlgorithm is the right thing to do here? rob From alee at redhat.com Thu Oct 25 15:07:50 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 25 Oct 2012 11:07:50 -0400 Subject: [Pki-devel] [PATCH] 79 - restrict AJP to localhost Message-ID: <1351177671.7507.20.camel@aleeredhat.laptop> Ticket 369 - Restrict AJP to localhost by default. Here is how I tested: 1. installed ipa master 2. installed ipa clone 3. Modified the ipa clone ipa-dogtag-proxy.conf file in /etc/httpd/conf.d to point to the master rather than localhost and restarted httpd. 4. Tried to access https:///ca/admin/ca/getStatus and https:///ca/admin/ca/getStatus Before the change, I am able to reach the page from both URIs. With the change, the page is only accessible from the master. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0079-Restrict-AJP-to-localhost-only-by-default.patch Type: text/x-patch Size: 3894 bytes Desc: not available URL: From cfu at redhat.com Thu Oct 25 17:55:39 2012 From: cfu at redhat.com (Christina Fu) Date: Thu, 25 Oct 2012 10:55:39 -0700 Subject: [Pki-devel] Fwd: [Freeipa-users] SHA-1 certificate support In-Reply-To: <508947BD.2080501@redhat.com> References: <5088496D.1070309@redhat.com> <20121024203836.GB29052@redhat.com> <508947BD.2080501@redhat.com> Message-ID: <50897D1B.3060105@redhat.com> On 10/25/2012 07:07 AM, Rob Crittenden wrote: > Nalin Dahyabhai wrote: >> On Wed, Oct 24, 2012 at 04:02:53PM -0400, Rob Crittenden wrote: >>> I assume he'd have to modify a profile to do this? >> >> There are two signatures when you're talking about using a CSR to >> request a certificate from an external CA. >> >> There's the digest used for the signature that the issuer includes in >> the certificate. In Dogtag, I believe that the allowed types are >> enumerated (by a signingAlgConstraint) in the profile, and the default >> is specified (as "ca.signing.defaultSigningAlgorithm") in the CA's >> CS.cfg file. >> >> Someone please correct me if I'm looking at the wrong places there. >> >> Then there's the digest used for the self-signature that the client >> includes in the CSR. The IPA installs script uses certutil, and it >> looks like certutil uses SHA1 by default. That's fine for this user, >> but I'll note that we can apparently use certutil's (undocumented?) -Z >> flag to switch that to something like SHA256. > > The CSR is generated by dogtag. I'm not sure if it forks out to > certutil or not but I'd suspect it doesn't. > > Can someone from the CS team confirm that changing the > defaultSigningAlgorithm is the right thing to do here? > Andrew is correct that you can also just change the following line in the profile (the "-" is telling the server to use the CA's default one from the CS.cfg) so it will only affect that particular profile: policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=- to policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA > rob > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Thu Oct 25 19:09:16 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 25 Oct 2012 15:09:16 -0400 Subject: [Pki-devel] [PATCH] 31 Fix for Ticket 384 in Dogtag 10.0 for review Message-ID: <1351192156.19216.4.camel@akoneru.redhat.com> Please review the patch attached fixing the ticket 384 of Dogtag10.0 tickets. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0031-Fix-for-ticket-384-Incorrect-profiles-path-reference.patch Type: text/x-patch Size: 3071 bytes Desc: not available URL: From alee at redhat.com Thu Oct 25 19:51:20 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 25 Oct 2012 15:51:20 -0400 Subject: [Pki-devel] [PATCH] 31 Fix for Ticket 384 in Dogtag 10.0 for review In-Reply-To: <1351192156.19216.4.camel@akoneru.redhat.com> References: <1351192156.19216.4.camel@akoneru.redhat.com> Message-ID: <1351194681.7507.25.camel@aleeredhat.laptop> NACK This is not exactly what we had in mind. Why not simply do this instead? config = CMS.getConfigStore().getString("profile." + id + ".config"); Ade On Thu, 2012-10-25 at 15:09 -0400, Abhishek Koneru wrote: > Please review the patch attached fixing the ticket 384 of Dogtag10.0 > tickets. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Oct 26 02:29:47 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 25 Oct 2012 21:29:47 -0500 Subject: [Pki-devel] [PATCH] 130 Enabled Tomcat security manager. In-Reply-To: <5085C3A2.4040001@redhat.com> References: <506CC3D0.10806@redhat.com> <5085C3A2.4040001@redhat.com> Message-ID: <5089F59B.6000600@redhat.com> On 10/22/2012 5:07 PM, Endi Sukma Dewata wrote: > On 10/3/2012 6:01 PM, Endi Sukma Dewata wrote: >> The tomcat.conf and pkideployment.cfg have been modified to enable >> the security manager. The catalina.policy has been updated with >> more specific permissions for PKI. >> >> Ticket #223 > > New patch attached. It will now combine the default Tomcat policy with > PKI standard policy and custom policy. New patch attached. It fixes pki.policy and the code to generate catalina.policy. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0130-3-Enabled-Tomcat-security-manager.patch Type: text/x-patch Size: 22571 bytes Desc: not available URL: From alee at redhat.com Fri Oct 26 02:59:46 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 25 Oct 2012 22:59:46 -0400 Subject: [Pki-devel] [PATCH] 79 - restrict AJP to localhost In-Reply-To: <1351177671.7507.20.camel@aleeredhat.laptop> References: <1351177671.7507.20.camel@aleeredhat.laptop> Message-ID: <1351220387.7507.26.camel@aleeredhat.laptop> acked by Endi. Pushed to master. On Thu, 2012-10-25 at 11:07 -0400, Ade Lee wrote: > Ticket 369 - Restrict AJP to localhost by default. > > Here is how I tested: > 1. installed ipa master > 2. installed ipa clone > 3. Modified the ipa clone ipa-dogtag-proxy.conf file > in /etc/httpd/conf.d to point to the master rather than localhost and > restarted httpd. > 4. Tried to access https:///ca/admin/ca/getStatus and > https:///ca/admin/ca/getStatus > > Before the change, I am able to reach the page from both URIs. With the > change, the page is only accessible from the master. > > Please review. > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Oct 26 04:31:09 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 25 Oct 2012 23:31:09 -0500 Subject: [Pki-devel] [PATCH] 145 Enabled authentication for key services. Message-ID: <508A120D.7070001@redhat.com> The web.xml in KRA has been modified to enable the authentication for key and key request services. Some tools have been added to access the services via command-line. Ticket #376 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0145-Enabled-authentication-for-key-services.patch Type: text/x-patch Size: 62350 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 26 04:39:16 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 25 Oct 2012 23:39:16 -0500 Subject: [Pki-devel] [PATCH] 144 Enabled account service for TKS and OCSP. In-Reply-To: <5088B26D.1030005@redhat.com> References: <5088B26D.1030005@redhat.com> Message-ID: <508A13F4.2070304@redhat.com> On 10/24/2012 10:30 PM, Endi Sukma Dewata wrote: > The REST account service has been added to TKS and OCSP to enable > authentication. > > Ticket #375 ACKed by Ade. Pushed to master. -- Endi S. Dewata From alee at redhat.com Fri Oct 26 15:18:14 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 26 Oct 2012 11:18:14 -0400 Subject: [Pki-devel] [PATCH] 142 Added REST interface to get domain info. In-Reply-To: <508705CD.4050101@redhat.com> References: <508705CD.4050101@redhat.com> Message-ID: <1351264694.7507.33.camel@aleeredhat.laptop> Overall the changes look good. The only concern I have is with the conflating of the ports in the security domain entries. While it is true that in the newer instances we used shared ports, the older instances (dogtag 9) used separated ports by default. Different services are available on different ports for these instances, and there is code in the installation servlets to parse the correct ports from the domain info returned from the security domain. Without this, installations of clones, intersystem interactions etc. can fail. So - please include support for all current ports in the domain. Ade On Tue, 2012-10-23 at 16:02 -0500, Endi Sukma Dewata wrote: > The REST interface for security domain has been updated to provide > a method to get the domain info. A CLI has been provided to access > this method. > > Ticket #309 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Oct 26 16:20:13 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 26 Oct 2012 11:20:13 -0500 Subject: [Pki-devel] [PATCH] 146 Added ACLInterceptor. Message-ID: <508AB83D.5050005@redhat.com> Previously ACL checking was done in PKIRealm by matching the URL. This code has been replaced by ACLInterceptor which will intercept RESTEasy method invocations. This allows more precise mapping of REST methods to ACL entries in acl.ldif. Ticket #287 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0146-Added-ACLInterceptor.patch Type: text/x-patch Size: 33477 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 26 18:15:48 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 26 Oct 2012 13:15:48 -0500 Subject: [Pki-devel] [PATCH] 142 Added REST interface to get domain info. In-Reply-To: <1351264694.7507.33.camel@aleeredhat.laptop> References: <508705CD.4050101@redhat.com> <1351264694.7507.33.camel@aleeredhat.laptop> Message-ID: <508AD354.7080605@redhat.com> On 10/26/2012 10:18 AM, Ade Lee wrote: > Overall the changes look good. The only concern I have is with the > conflating of the ports in the security domain entries. While it is > true that in the newer instances we used shared ports, the older > instances (dogtag 9) used separated ports by default. > > Different services are available on different ports for these instances, > and there is code in the installation servlets to parse the correct > ports from the domain info returned from the security domain. Without > this, installations of clones, intersystem interactions etc. can fail. > > So - please include support for all current ports in the domain. > > Ade New patch attached. Restored the agent, admin, and EE client auth ports. Removed the legacy code to read domain.xml file. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0142-1-Added-REST-interface-to-get-domain-info.patch Type: text/x-patch Size: 47179 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 26 21:03:34 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 26 Oct 2012 16:03:34 -0500 Subject: [Pki-devel] [PATCH] 142 Added REST interface to get domain info. In-Reply-To: <508AD354.7080605@redhat.com> References: <508705CD.4050101@redhat.com> <1351264694.7507.33.camel@aleeredhat.laptop> <508AD354.7080605@redhat.com> Message-ID: <508AFAA6.7010002@redhat.com> On 10/26/2012 1:15 PM, Endi Sukma Dewata wrote: > On 10/26/2012 10:18 AM, Ade Lee wrote: >> Overall the changes look good. The only concern I have is with the >> conflating of the ports in the security domain entries. While it is >> true that in the newer instances we used shared ports, the older >> instances (dogtag 9) used separated ports by default. >> >> Different services are available on different ports for these instances, >> and there is code in the installation servlets to parse the correct >> ports from the domain info returned from the security domain. Without >> this, installations of clones, intersystem interactions etc. can fail. >> >> So - please include support for all current ports in the domain. >> >> Ade > > New patch attached. Restored the agent, admin, and EE client auth ports. > Removed the legacy code to read domain.xml file. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Oct 26 21:03:36 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 26 Oct 2012 16:03:36 -0500 Subject: [Pki-devel] [PATCH] 143 Refactored GetDomainXML servlet. In-Reply-To: <508705D2.7090206@redhat.com> References: <508705D2.7090206@redhat.com> Message-ID: <508AFAA8.2040408@redhat.com> On 10/23/2012 4:02 PM, Endi Sukma Dewata wrote: > The GetDomainXML servlet has been refactored to use the new > SecurityDomainProcessor. > > Ticket #309 ACKed by Ade. Pushed to master. -- Endi S. Dewata From mharmsen at redhat.com Sat Oct 27 00:06:47 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 26 Oct 2012 17:06:47 -0700 Subject: [Pki-devel] [PATCH] Removal of version numbers from jar file names Message-ID: <508B2597.80604@redhat.com> The attached patch addresses the following PKI issue: * TRAC Ticket #350 - Dogtag 10: Remove version numbers from PKI jar files . . . This patch was checked against the following PKI services (CA/KRA/OCSP/TKS as a single merged instance): * The Dogtag 10 versions of 'dogtag-pki-theme', 'pki-core', and 'pki-console' were all built, installed, and tested on a 64-bit Fedora 17 machine * None of the java jars under /usr/share/java/pki contain any embedded versions in their names, and there are no more symbolic links * The JNI 'symkey.jar' is a file and contains no embedded version in its name * CA o after reporting the previously encountered 'certutil -a' problem on the admin cert, and manually correcting it, I successfully requested, approved, and issued a certificate using the 'Maual User Dual-Use Certificate Enrollment' profile * KRA o after launching a standalone browser profile (since the KRA admin certificate will not be prompted for since it is running on the same port), the keys were successfully archived using the 'Manual User Signing and Encryption Certificates Enrollment' profile * OCSP o after launching another standalone browser profile (since the KRA admin certificate will not be prompted for since it is running on the same port), the command 'OCSPClient server.example.com 8080 /var/lib/pki/pki-tomcat/alias/ "ocspSigningCert cert-pki-tomcat" 23 22.res 1 /ocsp/ee/ocsp' was executed from the command line while performing a 'tail -f /var/log/pki/pki-tomcat/ocsp/debug' which showed communication with the OCSP server * TKS o I successfully launched the URL 'http://server.example.com:8080/tks/services' from a browser * PKI Console o No GUI was presented for the PKI console when invoking 'pkiconsole https://server.example.com:8443/ca', but this appeared to be a display issue, not a problem with the newly named jars If this patch is found to be acceptable in its current incarnation, please feel free to push it to the 'master' branch so that it may be included in the upcoming Beta 2 builds. -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Removal-of-version-numbers-from-jar-file-names.patch Type: text/x-patch Size: 23318 bytes Desc: not available URL: From mharmsen at redhat.com Sat Oct 27 02:39:24 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 26 Oct 2012 19:39:24 -0700 Subject: [Pki-devel] [PATCH] 130 Enabled Tomcat security manager. In-Reply-To: <5089F59B.6000600@redhat.com> References: <506CC3D0.10806@redhat.com> <5085C3A2.4040001@redhat.com> <5089F59B.6000600@redhat.com> Message-ID: <508B495C.4070303@redhat.com> On 10/25/12 19:29, Endi Sukma Dewata wrote: > On 10/22/2012 5:07 PM, Endi Sukma Dewata wrote: >> On 10/3/2012 6:01 PM, Endi Sukma Dewata wrote: >>> The tomcat.conf and pkideployment.cfg have been modified to enable >>> the security manager. The catalina.policy has been updated with >>> more specific permissions for PKI. >>> >>> Ticket #223 >> >> New patch attached. It will now combine the default Tomcat policy with >> PKI standard policy and custom policy. > > New patch attached. It fixes pki.policy and the code to generate > catalina.policy. > ACK Applied patch, built, installed, and successfully tested a CA running under the Tomcat Java Security Manager: * # ps -ef | grep tomcat pkiuser 28050 1 2 19:15 ? 00:00:17 /usr/lib/jvm/jre/bin/java -classpath :/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp *-Djava.security.manager -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy* -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start I noticed one oddity in the '/usr/sbin/tomcat' file where they had specified*-Djava.security.policy=="${CATALINA_BASE}/conf/catalina.policy"* rather than *-Djava.security.policy="${CATALINA_BASE}/conf/catalina.policy"* (used an "==" rather than an single "="), but when I manually changed this, and restarted the server, I was still able to successfully request, approve, and issue another cert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Sat Oct 27 04:39:38 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 26 Oct 2012 23:39:38 -0500 Subject: [Pki-devel] [PATCH] 130 Enabled Tomcat security manager. In-Reply-To: <508B495C.4070303@redhat.com> References: <506CC3D0.10806@redhat.com> <5085C3A2.4040001@redhat.com> <5089F59B.6000600@redhat.com> <508B495C.4070303@redhat.com> Message-ID: <508B658A.3040704@redhat.com> On 10/26/2012 9:39 PM, Matthew Harmsen wrote: > ACK > > Applied patch, built, installed, and successfully tested a CA running > under the Tomcat Java Security Manager: > > * # ps -ef | grep tomcat > pkiuser 28050 1 2 19:15 ? 00:00:17 > /usr/lib/jvm/jre/bin/java -classpath > :/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar > -Dcatalina.base=/var/lib/pki/pki-tomcat > -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= > -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp > *-Djava.security.manager > -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy* -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > org.apache.catalina.startup.Bootstrap start > > I noticed one oddity in the '/usr/sbin/tomcat' file where they had > specified*-Djava.security.policy=="${CATALINA_BASE}/conf/catalina.policy"* > rather than > *-Djava.security.policy="${CATALINA_BASE}/conf/catalina.policy"* (used > an "==" rather than an single "="), but when I manually changed this, > and restarted the server, I was still able to successfully request, > approve, and issue another cert. Yes, single equal sign means we append the catalina.policy to the standard Java policy (/usr/lib/jvm/jre/lib/security/java.policy). The double equal signs mean that we use catalina.policy exclusively. http://download.java.net/jdk8/docs/technotes/guides/security/PolicyFiles.html Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Sat Oct 27 14:33:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 27 Oct 2012 09:33:01 -0500 Subject: [Pki-devel] [PATCH] Removal of version numbers from jar file names In-Reply-To: <508B2597.80604@redhat.com> References: <508B2597.80604@redhat.com> Message-ID: <508BF09D.4060506@redhat.com> On 10/26/2012 7:06 PM, Matthew Harmsen wrote: > * The JNI 'symkey.jar' is a file and contains no embedded version in > its name Please take a look at the following code in base/symkey/src/CMakeLists.txt: install( FILES ${CMAKE_BINARY_DIR}/dist/symkey.jar DESTINATION ${LIB_INSTALL_DIR}/symkey -- (A) ) install( FILES ${CMAKE_BINARY_DIR}/dist/symkey.jar DESTINATION ${JAVA_LIB_INSTALL_DIR} -- (B) ) and in pki-core.spec: cd %{buildroot}%{_libdir}/symkey %if 0%{?fedora} >= 16 %{__rm} %{buildroot}%{_jnidir}/symkey.jar -- (C) %{__mv} symkey.jar %{buildroot}%{_jnidir}/symkey.jar -- (D) %else %{__rm} symkey.jar -- (E) %{__ln_s} symkey-%{version}.jar symkey.jar -- (F) %endif %if 0%{?rhel} || 0%{?fedora} < 16 cd %{buildroot}%{_jnidir} %{__rm} symkey.jar -- (G) %{__ln_s} %{_libdir}/symkey/symkey.jar symkey.jar -- (H) %endif Some observations: 1. In A and B the code installs symkey.jar in /usr/lib64/symkey and /usr/lib64/java, respectively. In C the symkey.jar is removed from /usr/lib64/java. In D the symkey.jar is moved from /usr/lib64/symkey to /usr/lib64/java. It seems that the code in A, C, and D is not needed since we have B. 2. The code in E & F doesn't seem to be needed anymore since we don't support anything before F16. 3. The code in G & H removes the symkey.jar in /usr/lib64/java and replaces it with a link to symkey.jar in /usr/lib64/symkey. This is not necessary since we have B. If these are correct we probably can remove everything above except B. Other than that the patch looks good, ACK. -- Endi S. Dewata From edewata at redhat.com Mon Oct 29 15:42:04 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 29 Oct 2012 10:42:04 -0500 Subject: [Pki-devel] [PATCH] 125 Fixed synchronization problem in CertificateRepository. In-Reply-To: <5080782A.1060109@redhat.com> References: <50627274.7010304@redhat.com> <5065E9F6.70006@redhat.com> <5069A409.6020301@redhat.com> <1349102645.2575.102.camel@aleeredhat.laptop> <5080782A.1060109@redhat.com> Message-ID: <508EA3CC.7000802@redhat.com> On 10/18/2012 4:44 PM, Endi Sukma Dewata wrote: > New patch attached. As discussed, this patch will now revert the code > structure to be similar to the one in the Dogtag 9, meaning the point #1 > and #2 above will also be reverted. I hope this is sufficient to address > the synchronization issue in ticket #313. Further clean up can be done > separately. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Oct 29 15:42:10 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 29 Oct 2012 10:42:10 -0500 Subject: [Pki-devel] [PATCH] 145 Enabled authentication for key services. In-Reply-To: <508A120D.7070001@redhat.com> References: <508A120D.7070001@redhat.com> Message-ID: <508EA3D2.2090800@redhat.com> On 10/25/2012 11:31 PM, Endi Sukma Dewata wrote: > The web.xml in KRA has been modified to enable the authentication > for key and key request services. Some tools have been added to > access the services via command-line. > > Ticket #376 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Oct 29 18:51:20 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 29 Oct 2012 13:51:20 -0500 Subject: [Pki-devel] [PATCH] 146 Added ACLInterceptor. In-Reply-To: <508AB83D.5050005@redhat.com> References: <508AB83D.5050005@redhat.com> Message-ID: <508ED028.3050206@redhat.com> On 10/26/2012 11:20 AM, Endi Sukma Dewata wrote: > Previously ACL checking was done in PKIRealm by matching the URL. > This code has been replaced by ACLInterceptor which will intercept > RESTEasy method invocations. This allows more precise mapping of > REST methods to ACL entries in acl.ldif. > > Ticket #287 New patch attached. Fixed missing ACL mappings and revised some REST interfaces. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0146-1-Added-ACLInterceptor.patch Type: text/x-patch Size: 44769 bytes Desc: not available URL: From akoneru at redhat.com Mon Oct 29 19:28:21 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 29 Oct 2012 15:28:21 -0400 Subject: [Pki-devel] Patch 31 -2 Fix for comments given for [PATCH] 31 Fix for Ticket 384 in Dogtag 10.0 for review In-Reply-To: <1351194681.7507.25.camel@aleeredhat.laptop> References: <1351192156.19216.4.camel@akoneru.redhat.com> <1351194681.7507.25.camel@aleeredhat.laptop> Message-ID: <1351538901.7410.2.camel@akoneru.redhat.com> Please find attached the patch with fixes for the comment given for Patch 31 for review. --Abhishek On Thu, 2012-10-25 at 15:51 -0400, Ade Lee wrote: > NACK > > This is not exactly what we had in mind. Why not simply do this > instead? > > config = CMS.getConfigStore().getString("profile." + id + ".config"); > > Ade > > On Thu, 2012-10-25 at 15:09 -0400, Abhishek Koneru wrote: > > Please review the patch attached fixing the ticket 384 of Dogtag10.0 > > tickets. > > > > --Abhishek > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0031-2-Fix-for-ticket-384-Incorrect-profiles-path-reference.patch Type: text/x-patch Size: 3186 bytes Desc: not available URL: From mharmsen at redhat.com Mon Oct 29 19:36:19 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 29 Oct 2012 12:36:19 -0700 Subject: [Pki-devel] [PATCH] Removal of version numbers from jar file names In-Reply-To: <508BF09D.4060506@redhat.com> References: <508B2597.80604@redhat.com> <508BF09D.4060506@redhat.com> Message-ID: <508EDAB3.6030409@redhat.com> Endi, Comments in-line. On 10/27/12 07:33, Endi Sukma Dewata wrote: > On 10/26/2012 7:06 PM, Matthew Harmsen wrote: >> * The JNI 'symkey.jar' is a file and contains no embedded version in >> its name > > Please take a look at the following code in > base/symkey/src/CMakeLists.txt: > > install( > FILES > ${CMAKE_BINARY_DIR}/dist/symkey.jar > DESTINATION > ${LIB_INSTALL_DIR}/symkey -- (A) > ) > '${LIB_INSTALL_DIR}' is defined in 'pki/cmake/Modules/DefineInstallationPaths.cmake' as '${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX}' which basically places 'symkey.jar' into 'usr/lib/symkey' (32-bit) or 'usr/lib64/symkey' (64-bit) unless this is being somehow overridden by a newer version of cmake? > install( > FILES > ${CMAKE_BINARY_DIR}/dist/symkey.jar > DESTINATION > ${JAVA_LIB_INSTALL_DIR} -- (B) > ) > '${JAVA_LIB_INSTALL_DIR}' is defined in 'pki/cmake/Modules/DefineInstallationPaths.cmake' as '${CMAKE_INSTALL_PREFIX}/lib/java' which basically places 'symkey.jar' into 'usr/lib/java' (32-bit & 64-bit) unless this is being somehow overridden by a newer version of cmake? > and in pki-core.spec: > > cd %{buildroot}%{_libdir}/symkey > %if 0%{?fedora} >= 16 > %{__rm} %{buildroot}%{_jnidir}/symkey.jar -- (C) > %{__mv} symkey.jar %{buildroot}%{_jnidir}/symkey.jar -- (D) > %else > %{__rm} symkey.jar -- (E) > %{__ln_s} symkey-%{version}.jar symkey.jar -- (F) > %endif > For Fedora 16 and greater, this removes 'symkey.jar' on 32-bit and removes nothing on 64-bit systems, and moves symkey.jar under the appropriate 'usr/lib/java' (32-bit) and 'usr/lib64/java' (64-bit). This code block may not be necessary if we make the change I suggest below. As RHEL 5, RHEL 6, and Fedora 17 or less are not supported, and we are not yet certain of the RHEL 7 changes for JNI, I agree that the %else code block could be removed. > %if 0%{?rhel} || 0%{?fedora} < 16 > cd %{buildroot}%{_jnidir} > %{__rm} symkey.jar -- (G) > %{__ln_s} %{_libdir}/symkey/symkey.jar symkey.jar -- (H) > %endif > Since this code exists on the 'master', and RHEL 5, RHEL 6, and Fedora 15 or less are not supported, and we are not yet certain of the RHEL 7 changes for JNI, I agree that this code block could be removed. > Some observations: > > 1. In A and B the code installs symkey.jar in /usr/lib64/symkey and > /usr/lib64/java, respectively. In C the symkey.jar is removed from > /usr/lib64/java. In D the symkey.jar is moved from /usr/lib64/symkey > to /usr/lib64/java. It seems that the code in A, C, and D is not > needed since we have B. > > 2. The code in E & F doesn't seem to be needed anymore since we don't > support anything before F16. > > 3. The code in G & H removes the symkey.jar in /usr/lib64/java and > replaces it with a link to symkey.jar in /usr/lib64/symkey. This is > not necessary since we have B. > > If these are correct we probably can remove everything above except B. > Per my comments above, I think that we could remove everything above except B by making the following changes (I need to do test builds on 32-bit and 64-bit systems to prove this theory) from: install( FILES ${CMAKE_BINARY_DIR}/dist/symkey.jar DESTINATION *${JAVA_LIB_INSTALL_DIR}* -- (B) ) to: install( FILES ${CMAKE_BINARY_DIR}/dist/symkey.jar DESTINATION *${LIB_INSTALL_DIR}/java* -- (B) ) Do you agree with this approach? > Other than that the patch looks good, ACK. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Oct 29 20:59:17 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 29 Oct 2012 16:59:17 -0400 Subject: [Pki-devel] Patch 31 -2 Fix for comments given for [PATCH] 31 Fix for Ticket 384 in Dogtag 10.0 for review In-Reply-To: <1351538901.7410.2.camel@akoneru.redhat.com> References: <1351192156.19216.4.camel@akoneru.redhat.com> <1351194681.7507.25.camel@aleeredhat.laptop> <1351538901.7410.2.camel@akoneru.redhat.com> Message-ID: <1351544357.7507.37.camel@aleeredhat.laptop> Some new warnings about unused variables. Fixed and pushed to master. Ade On Mon, 2012-10-29 at 15:28 -0400, Abhishek Koneru wrote: > Please find attached the patch with fixes for the comment given for > Patch 31 for review. > > --Abhishek > > On Thu, 2012-10-25 at 15:51 -0400, Ade Lee wrote: > > NACK > > > > This is not exactly what we had in mind. Why not simply do this > > instead? > > > > config = CMS.getConfigStore().getString("profile." + id + ".config"); > > > > Ade > > > > On Thu, 2012-10-25 at 15:09 -0400, Abhishek Koneru wrote: > > > Please review the patch attached fixing the ticket 384 of Dogtag10.0 > > > tickets. > > > > > > --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 mharmsen at redhat.com Tue Oct 30 05:20:10 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 29 Oct 2012 22:20:10 -0700 Subject: [Pki-devel] [PATCH] Allow a PKI instance to be installed/configured independently Message-ID: <508F638A.10008@redhat.com> The attached patch addresses the following PKI issue: * TRAC Ticket #286 - Dogtag 10: Create parameter for optionally allowing a user to skip configuration . . . This patch was tested successfully with the following new parameter specifications: 1. standard 'pkispawn' combined installation/configuration: * pki_skip_configuration=False * pki_skip_installation=False 2. legacy 'pkispawn' run like 'pkicreate'/'browser UI configuration: * pki_skip_configuration=True * pki_skip_installation=False 3. run 'pkispawn' skipping installation and configuration (do nothing) * pki_skip_configuration=True * pki_skip_installation=True The patch was not tested for running 'pkispawn' first for installation only (2), and then again only for configuration (which may or may not work). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20121029-Allow-a-PKI-instance-to-be-installed-configured-inde.patch Type: text/x-patch Size: 17831 bytes Desc: not available URL: From alee at redhat.com Tue Oct 30 14:59:28 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 30 Oct 2012 10:59:28 -0400 Subject: [Pki-devel] [PATCH] Allow a PKI instance to be installed/configured independently In-Reply-To: <508F638A.10008@redhat.com> References: <508F638A.10008@redhat.com> Message-ID: <1351609168.25507.0.camel@aleeredhat.laptop> ack - pushed to master. On Mon, 2012-10-29 at 22:20 -0700, Matthew Harmsen wrote: > The attached patch addresses the following PKI issue: > * TRAC Ticket #286 - Dogtag 10: Create parameter for optionally > allowing a user to skip configuration . . . > This patch was tested successfully with the following new parameter > specifications: > 1. standard 'pkispawn' combined installation/configuration: > * pki_skip_configuration=False > * pki_skip_installation=False > 2. legacy 'pkispawn' run like 'pkicreate'/'browser UI > configuration: > * pki_skip_configuration=True > * pki_skip_installation=False > 3. run 'pkispawn' skipping installation and configuration (do > nothing) > * pki_skip_configuration=True > * pki_skip_installation=True > The patch was not tested for running 'pkispawn' first for installation > only (2), and then again only for configuration (which may or may not > work). > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Oct 30 16:11:18 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 30 Oct 2012 11:11:18 -0500 Subject: [Pki-devel] [PATCH] 147 Fixed PrettyPrintCert and PrettyPrintCrl. Message-ID: <508FFC26.6080303@redhat.com> The wrappers for PrettyPrintCert and PrettyPrintCrl has been fixed to include the class names. Ticket #381 There's still an exception about missing SHA 256 message digest, but it will be addressed separately. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0147-Fixed-PrettyPrintCert-and-PrettyPrintCrl.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: From alee at redhat.com Tue Oct 30 19:17:01 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 30 Oct 2012 15:17:01 -0400 Subject: [Pki-devel] Announcing Dogtag 10 Beta 2 Release Message-ID: <1351624621.25507.43.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 beta 2. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.48.b2.fc18 pki-ra-10.0.0-0.10.b2.fc18 pki-tps-10.0.0-0.10.b2.fc18 dogtag-pki-10.0.0-0.13.b2.fc18 dogtag-pki-theme-10.0.0-0.4.b2.fc18 pki-console-10.0.0-0.10.b2.fc18 == Highlights since Dogtag v. 10.0.0 beta 1 (Oct 9 2012) == * Selinux policy moved into system selinux policy. For F18, pki-selinux will no longer be built and delivered by the dogtag team. The PKI policy will instead be managed by the selinux base packages team. * Added option to install schema on a clone, rather than simply replicating it. This is to resolve an IPA issue when replicating from a non-merged to a merged database. * Restricted AJP to allow access from localhost only by default. This is an IPA reported issue. * Changes to allow the TPS and RA to install and configure correctly. * Enabled Tomcat security manager and added mechanism to configure custom security policy. * Added CLI tools to obtain security domain information and install tokens. * Refactored REST client classes to support multiple operations over authenticated HTTP session. * Added automatic recovery to the LDAP modification listener. * Added login service to protect REST services including certificate operations, key operations, security domain, TKS and OCSP. * Added option to pkispawn to exit before configuration, in case the installer wants to go through the UI configuration panels. In this way, pkispawn can be operated like pkicreate/pkisilent. * Removed version numbers from jar files to comply with Fedora packaging recommendations. == Notes for F17 == * Only developer builds are available for F17. * F17 tomcat used to have a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you have at least tomcat-7.0.32-1.fc17. == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == akoneru (1): 1485a05 Fix for ticket 384 - Incorrect profiles path referenced alee (15): 80ac796 Fix symkey build dependency 65c17da Update to b2 release 7c105a6 Restrict AJP to localhost only by default 3908d96 Added obsoletes for pki-selinux 278ee60 changes to remove pki-selinux from f18 build 1c45197 Provide option to install, rather than replicate schema to clone 40bcc2c Reorder VLV indexing for clones to avoid errors 643c089 Fixes to get TPS to configure correctly d6634a7 Reverted to old interface and httpclient for installation token. 2a43f48 Added net-tools dependency 35eb608 changes to remind folks not to use pkicreate/pkiremove 8a2d342 Update tomcatjss dependency 283af42 Added pki_tomcat_script_t type and rules for upgraded instances c7c2b6c New selinux interface needed for certmonger directory access c494bd0 Added pki_tomcat_cert_t type and interface to access it edewata (16): c1aa8b2 Enabled authentication for key services. 748605a Fixed synchronization problem in CertificateRepository. 5eab7fe Enabled Tomcat security manager. 9c17ef4 Refactored GetDomainXML servlet. 5bb7933 Added REST interface to get domain info. 6359021 Enabled account service for TKS and OCSP. 8687740 Added conditions for security domain REST service. 7ec6c91 Fixed error handling in RetrieveModificationsTask. 2d3d561 Fixed KRA test. c1f9b39 Enabled realm authentication for certificate requests. 1723a2e Added REST account service. 98ad9c1 Added PKIPrincipal. 4300459 Added PKIConnection. 8973480 Refactored GetCookie servlet. 168d954 Enabled authentication for security domain REST interface. 212ab82 Return to d9 behavior for RetrieveModificationsTask mharmsen (2): a957a3d Allow a PKI instance to be installed/configured independently 8d77b52 Removal of version numbers from jar file names From edewata at redhat.com Tue Oct 30 23:21:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 30 Oct 2012 18:21:53 -0500 Subject: [Pki-devel] [PATCH] 148 Fixed problem finding SHA-256 message digest. Message-ID: <50906111.2030603@redhat.com> The CertPrettyPrint has been modified to use the standard names for message digests so that it will work with standard security provider. Ticket #392 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0148-Fixed-problem-finding-SHA-256-message-digest.patch Type: text/x-patch Size: 1318 bytes Desc: not available URL: From alee at redhat.com Wed Oct 31 02:47:43 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 30 Oct 2012 22:47:43 -0400 Subject: [Pki-devel] [PATCH] 148 Fixed problem finding SHA-256 message digest. In-Reply-To: <50906111.2030603@redhat.com> References: <50906111.2030603@redhat.com> Message-ID: <1351651663.25507.48.camel@aleeredhat.laptop> nice find. ack On Tue, 2012-10-30 at 18:21 -0500, Endi Sukma Dewata wrote: > The CertPrettyPrint has been modified to use the standard names > for message digests so that it will work with standard security > provider. > > Ticket #392 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Oct 31 02:48:02 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 30 Oct 2012 22:48:02 -0400 Subject: [Pki-devel] [PATCH] 147 Fixed PrettyPrintCert and PrettyPrintCrl. In-Reply-To: <508FFC26.6080303@redhat.com> References: <508FFC26.6080303@redhat.com> Message-ID: <1351651683.25507.49.camel@aleeredhat.laptop> ack On Tue, 2012-10-30 at 11:11 -0500, Endi Sukma Dewata wrote: > The wrappers for PrettyPrintCert and PrettyPrintCrl has been fixed > to include the class names. > > Ticket #381 > > There's still an exception about missing SHA 256 message digest, but it > will be addressed separately. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Wed Oct 31 14:50:43 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 31 Oct 2012 09:50:43 -0500 Subject: [Pki-devel] [PATCH] 147 Fixed PrettyPrintCert and PrettyPrintCrl. In-Reply-To: <1351651683.25507.49.camel@aleeredhat.laptop> References: <508FFC26.6080303@redhat.com> <1351651683.25507.49.camel@aleeredhat.laptop> Message-ID: <50913AC3.1080804@redhat.com> On 10/30/2012 9:48 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Oct 31 14:50:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 31 Oct 2012 09:50:53 -0500 Subject: [Pki-devel] [PATCH] 148 Fixed problem finding SHA-256 message digest. In-Reply-To: <1351651663.25507.48.camel@aleeredhat.laptop> References: <50906111.2030603@redhat.com> <1351651663.25507.48.camel@aleeredhat.laptop> Message-ID: <50913ACD.9080908@redhat.com> On 10/30/2012 9:47 PM, Ade Lee wrote: > nice find. ack Pushed to master. Thanks. -- Endi S. Dewata From cfu at redhat.com Wed Oct 31 17:30:03 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 31 Oct 2012 10:30:03 -0700 Subject: [Pki-devel] test Message-ID: <5091601B.10606@redhat.com> test From alee at redhat.com Wed Oct 31 17:34:56 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 31 Oct 2012 13:34:56 -0400 Subject: [Pki-devel] test In-Reply-To: <5091601B.10606@redhat.com> References: <5091601B.10606@redhat.com> Message-ID: <1351704897.8342.18.camel@aleeredhat.laptop> Responding to the test. On Wed, 2012-10-31 at 10:30 -0700, Christina Fu wrote: > test > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel