From ayoung at redhat.com Thu Dec 1 02:23:12 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 30 Nov 2011 21:23:12 -0500 Subject: [Pki-devel] Probably worth a read prior to the .Next effort Message-ID: <4ED6E510.4070200@redhat.com> http://books.slashdot.org/story/11/11/30/2216218/book-review-the-cert-oracle-secure-coding-standard-for-java I'll see if I can scare up a copy. From edewata at redhat.com Thu Dec 1 15:23:55 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 01 Dec 2011 09:23:55 -0600 Subject: [Pki-devel] [PATCH] 2 Added JUnit report generator. Message-ID: <4ED79C0B.6060708@redhat.com> A custom JUnit test runner has been added to capture test results and generate XML reports. Ticket #36 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0002-Added-JUnit-report-generator.patch Type: text/x-patch Size: 13201 bytes Desc: not available URL: From edewata at redhat.com Thu Dec 1 16:28:46 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 01 Dec 2011 10:28:46 -0600 Subject: [Pki-devel] [PATCH] 3 Fixed stack trace in test report. Message-ID: <4ED7AB3E.4050307@redhat.com> The report generator has been fixed to show the stack trace from the test source code. Ticket #36 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0003-Fixed-stack-trace-in-test-report.patch Type: text/x-patch Size: 2564 bytes Desc: not available URL: From ayoung at redhat.com Thu Dec 1 19:06:39 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Dec 2011 14:06:39 -0500 Subject: [Pki-devel] [PATCH] 2 Added JUnit report generator. In-Reply-To: <4ED79C0B.6060708@redhat.com> References: <4ED79C0B.6060708@redhat.com> Message-ID: <4ED7D03F.9040907@redhat.com> On 12/01/2011 10:23 AM, Endi Sukma Dewata wrote: > A custom JUnit test runner has been added to capture test results > and generate XML reports. > > Ticket #36 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Runs fine the first time, but you can't run the test twice. [ayoung at ayoung core]$ make test mkdir: cannot create directory `reports': File exists make[3]: *** [base/common/test/CMakeFiles/test-pki-common] Error 1 make[2]: *** [base/common/test/CMakeFiles/test-pki-common.dir/all] Error 2 make[1]: *** [CMakeFiles/test.dir/rule] Error 2 make: *** [test] Error 2 Do mkdir -p instead -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Dec 1 19:14:30 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Dec 2011 14:14:30 -0500 Subject: [Pki-devel] [PATCH] 2 Added JUnit report generator. In-Reply-To: <4ED7D03F.9040907@redhat.com> References: <4ED79C0B.6060708@redhat.com> <4ED7D03F.9040907@redhat.com> Message-ID: <4ED7D216.6050401@redhat.com> On 12/01/2011 02:06 PM, Adam Young wrote: > On 12/01/2011 10:23 AM, Endi Sukma Dewata wrote: >> A custom JUnit test runner has been added to capture test results >> and generate XML reports. >> >> Ticket #36 >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Runs fine the first time, but you can't run the test twice. > > [ayoung at ayoung core]$ make test > mkdir: cannot create directory `reports': File exists > make[3]: *** [base/common/test/CMakeFiles/test-pki-common] Error 1 > make[2]: *** [base/common/test/CMakeFiles/test-pki-common.dir/all] Error 2 > make[1]: *** [CMakeFiles/test.dir/rule] Error 2 > make: *** [test] Error 2 > > > Do mkdir -p instead > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Also, the recompile doesn't seem to be getting triggered. I added a fail(); to a test .java file to trigger an exception, and nothing happened, then I ran make all and the make test and saw the stack trace. REmoving it, same thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Dec 1 19:16:10 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Dec 2011 14:16:10 -0500 Subject: [Pki-devel] [PATCH] 3 Fixed stack trace in test report. In-Reply-To: <4ED7AB3E.4050307@redhat.com> References: <4ED7AB3E.4050307@redhat.com> Message-ID: <4ED7D27A.7060703@redhat.com> On 12/01/2011 11:28 AM, Endi Sukma Dewata wrote: > The report generator has been fixed to show the stack trace from > the test source code. > > Ticket #36 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK, provisional on changes to Patch 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Dec 1 19:35:58 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Dec 2011 14:35:58 -0500 Subject: [Pki-devel] Patch status Message-ID: <4ED7D71E.80206@redhat.com> The following patches of mine need review still or an explicit ACK/NACK 0013-unnecessary-block-removal 0015-Removal-of-unused-private-methods 0017-call-statics-statically 0019-PKISilent-type-safety-changes From alee at redhat.com Thu Dec 1 20:10:55 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 01 Dec 2011 15:10:55 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch Message-ID: <1322770255.19378.52.camel@aleeredhat.laptop> Code formatting rules to be used in Eclipse for formatting once current patches are checked in. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch Type: text/x-patch Size: 24163 bytes Desc: not available URL: From edewata at redhat.com Thu Dec 1 20:16:23 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 01 Dec 2011 14:16:23 -0600 Subject: [Pki-devel] [PATCH] 2 Added JUnit report generator. In-Reply-To: <4ED7D216.6050401@redhat.com> References: <4ED79C0B.6060708@redhat.com> <4ED7D03F.9040907@redhat.com> <4ED7D216.6050401@redhat.com> Message-ID: <4ED7E097.609@redhat.com> On 12/1/2011 1:14 PM, Adam Young wrote: >> Runs fine the first time, but you can't run the test twice. >> >> [ayoung at ayoung core]$ make test >> mkdir: cannot create directory `reports': File exists >> make[3]: *** [base/common/test/CMakeFiles/test-pki-common] Error 1 >> make[2]: *** [base/common/test/CMakeFiles/test-pki-common.dir/all] Error 2 >> make[1]: *** [CMakeFiles/test.dir/rule] Error 2 >> make: *** [test] Error 2 >> >> Do mkdir -p instead Fixed in the new patch. > Also, the recompile doesn't seem to be getting triggered. I added a > fail(); to a test .java file to trigger an exception, and nothing > happened, then I ran make all and the make test and saw the stack trace. > REmoving it, same thing. Yes, I've put "TODO: build test only when the test is invoked". Right now the test files are only compiled under "all" target, it should have been under "test" target. I'm still not sure how to call add_jar() from a custom target. The add_custom_command() let's you add a command but not a function invocation. Maybe the whole common/test should be called under "test" too. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0002-2-Added-JUnit-report-generator.patch Type: text/x-patch Size: 13204 bytes Desc: not available URL: From ayoung at redhat.com Fri Dec 2 02:10:29 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Dec 2011 21:10:29 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <1322770255.19378.52.camel@aleeredhat.laptop> References: <1322770255.19378.52.camel@aleeredhat.laptop> Message-ID: <4ED83395.7040805@redhat.com> On 12/01/2011 03:10 PM, Ade Lee wrote: > Code formatting rules to be used in Eclipse for formatting once current > patches are checked in. > > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel The rules look OK. The name in my project shows up as : Unmanaged profile 'PKI Project Profile' Which looks like something wrapped 'PKI Project Profile' by accident I did a dry run of formatting the project [ayoung at ayoung pki]$ git diff | wc -l 387864 so it probably changes about 150K lines. Can someone else confirm that they can see the project specific settings and that the name is messed up? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Fri Dec 2 05:19:02 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 01 Dec 2011 21:19:02 -0800 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <4ED83395.7040805@redhat.com> References: <1322770255.19378.52.camel@aleeredhat.laptop> <4ED83395.7040805@redhat.com> Message-ID: <4ED85FC6.5080206@redhat.com> On 12/01/2011 06:10 PM, Adam Young wrote: > On 12/01/2011 03:10 PM, Ade Lee wrote: >> Code formatting rules to be used in Eclipse for formatting once current >> patches are checked in. >> >> Ade >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > The rules look OK. The name in my project shows up as : > Unmanaged profile 'PKI Project Profile' > > Which looks like something wrapped 'PKI Project Profile' by accident > > I did a dry run of formatting the project > [ayoung at ayoung pki]$ git diff | wc -l > 387864 > so it probably changes about 150K lines. The patch doesn't apply correctly for me using 'git am', so I had to fall back to 'git apply'. That said: [nkinder at localhost pki]$ git diff | wc -l 387843 > > Can someone else confirm that they can see the project specific > settings and that the name is messed up? I'm still new to Eclipse, so I'm not sure where to look for the name and settings you're referring to. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Fri Dec 2 14:39:14 2011 From: alee at redhat.com (Ade Lee) Date: Fri, 02 Dec 2011 09:39:14 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <4ED85FC6.5080206@redhat.com> References: <1322770255.19378.52.camel@aleeredhat.laptop> <4ED83395.7040805@redhat.com> <4ED85FC6.5080206@redhat.com> Message-ID: <1322836755.19378.54.camel@aleeredhat.laptop> Nathan, The patch may not have applied cleanly for you because it was done against the git svn instance -- on the assumption that we were going to blow away the git instance. If that isn't going to happen -- and my guess is that it will not, I will regenerate the patch on the git instance. Ade On Thu, 2011-12-01 at 21:19 -0800, Nathan Kinder wrote: > On 12/01/2011 06:10 PM, Adam Young wrote: > > On 12/01/2011 03:10 PM, Ade Lee wrote: > > > Code formatting rules to be used in Eclipse for formatting once current > > > patches are checked in. > > > > > > Ade > > > > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > The rules look OK. The name in my project shows up as : > > Unmanaged profile 'PKI Project Profile' > > > > Which looks like something wrapped 'PKI Project Profile' by > > accident > > > > I did a dry run of formatting the project > > [ayoung at ayoung pki]$ git diff | wc -l > > 387864 > > so it probably changes about 150K lines. > The patch doesn't apply correctly for me using 'git am', so I had to > fall back to 'git apply'. That said: > > [nkinder at localhost pki]$ git diff | wc -l > 387843 > > > > Can someone else confirm that they can see the project specific > > settings and that the name is messed up? > I'm still new to Eclipse, so I'm not sure where to look for the name > and settings you're referring to. > > > > > > _______________________________________________ > > 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 ayoung at redhat.com Fri Dec 2 14:51:52 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 09:51:52 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <4ED85FC6.5080206@redhat.com> References: <1322770255.19378.52.camel@aleeredhat.laptop> <4ED83395.7040805@redhat.com> <4ED85FC6.5080206@redhat.com> Message-ID: <4ED8E608.1080109@redhat.com> On 12/02/2011 12:19 AM, Nathan Kinder wrote: > On 12/01/2011 06:10 PM, Adam Young wrote: >> On 12/01/2011 03:10 PM, Ade Lee wrote: >>> Code formatting rules to be used in Eclipse for formatting once current >>> patches are checked in. >>> >>> Ade >>> >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> The rules look OK. The name in my project shows up as : >> Unmanaged profile 'PKI Project Profile' >> >> Which looks like something wrapped 'PKI Project Profile' by accident >> >> I did a dry run of formatting the project >> [ayoung at ayoung pki]$ git diff | wc -l >> 387864 >> so it probably changes about 150K lines. > The patch doesn't apply correctly for me using 'git am', so I had to > fall back to 'git apply'. That said: Ok, this is a known problem: Edit the patch by hand and remove the leading >. It is the email client that adds that. After that, the patch should apply. To get around this problem, appply this fix: Thunderbird has a nasty habit of prepending a > character to the patch, messing up the format. While it is trivial to edit the patch by hand to remove it, the patch sender can help out by configuring Thunderbird this way: * In Thunderbird Preferences, * Go to the Advanced->General tab. * Select "Config Editor" * Search for mail.file_attach_binary and * Set this value to true > > [nkinder at localhost pki]$ git diff | wc -l > 387843 >> >> Can someone else confirm that they can see the project specific >> settings and that the name is messed up? > I'm still new to Eclipse, so I'm not sure where to look for the name > and settings you're referring to. Windows->Preferences->Java ->Code Style Formatter->Configure Project Specific Settings (Link at the top right of the page) If the patch has been applied, and you click the checkbox that says : Show on Projects with Project Specific Settings, you should still see the pki project. Click OK, and you should see the porofile name in a drop down list. You can edit that by clicking "edit" to the right. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 14:55:15 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 09:55:15 -0500 Subject: [Pki-devel] Patch format guidlines Message-ID: <4ED8E6D3.8090103@redhat.com> We wrote this up for the IPA team awhile back, and I think it will help out the PKI team as well: https://fedorahosted.org/freeipa/wiki/PatchFormat Note that the part at the bottom about Thunderbird is still relevant. From nkinder at redhat.com Fri Dec 2 15:35:14 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 02 Dec 2011 07:35:14 -0800 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <1322836755.19378.54.camel@aleeredhat.laptop> References: <1322770255.19378.52.camel@aleeredhat.laptop> <4ED83395.7040805@redhat.com> <4ED85FC6.5080206@redhat.com> <1322836755.19378.54.camel@aleeredhat.laptop> Message-ID: <4ED8F032.6020005@redhat.com> On 12/02/2011 06:39 AM, Ade Lee wrote: > Nathan, > > The patch may not have applied cleanly for you because it was done > against the git svn instance -- on the assumption that we were going to > blow away the git instance. If that isn't going to happen -- and my > guess is that it will not, I will regenerate the patch on the git > instance. I thought that might be the case. Go ahead and generate it against the git repo. At this point, I see no reason to wipe out our git repo and re-import. > > Ade > > On Thu, 2011-12-01 at 21:19 -0800, Nathan Kinder wrote: >> On 12/01/2011 06:10 PM, Adam Young wrote: >>> On 12/01/2011 03:10 PM, Ade Lee wrote: >>>> Code formatting rules to be used in Eclipse for formatting once current >>>> patches are checked in. >>>> >>>> Ade >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> The rules look OK. The name in my project shows up as : >>> Unmanaged profile 'PKI Project Profile' >>> >>> Which looks like something wrapped 'PKI Project Profile' by >>> accident >>> >>> I did a dry run of formatting the project >>> [ayoung at ayoung pki]$ git diff | wc -l >>> 387864 >>> so it probably changes about 150K lines. >> The patch doesn't apply correctly for me using 'git am', so I had to >> fall back to 'git apply'. That said: >> >> [nkinder at localhost pki]$ git diff | wc -l >> 387843 >>> Can someone else confirm that they can see the project specific >>> settings and that the name is messed up? >> I'm still new to Eclipse, so I'm not sure where to look for the name >> and settings you're referring to. >>> >>> _______________________________________________ >>> 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 ayoung at redhat.com Fri Dec 2 15:39:07 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 10:39:07 -0500 Subject: [Pki-devel] [Freeipa-devel] Tomcat Realms and Directory Server In-Reply-To: <1322795076.22044.68.camel@willson.li.ssimo.org> References: <4EB970AB.9080807@redhat.com> <1322795076.22044.68.camel@willson.li.ssimo.org> Message-ID: <4ED8F11B.1040003@redhat.com> On 12/01/2011 10:04 PM, Simo Sorce wrote: > Hi Adam, > I haven't replied to this summary so far for 2 reasons. > I had little time to ponder it (and Java is not my forte) and it is > still a bit up in the air. > > I am a bit concerned about the relatively unstable/young support for > some of the tech that would have to be involved, but on the other hand I > tend to like the approach of better in depth security, auth forwarding, > and isolation of instances and credentials used. > > I think you should keep exploring this area and see what works and what > not. > > I wonder if the session work we are doing for the main IPA framework can > be used in some way to simplify part of the work you are doing. > Unfortunately working in Java may be an obstacle in this sense as we > plan to use python native marchalling/unmarshalling of objects in the > session cache, but keep in mind this may be an avenue to offload most of > the auth/session management work to the IPA framework and simplify your > credential management at least when dogtag is integrated with IPA. > > Simo. So I've learned a litle bit more since I wrote this. The Proxy code should forward over the Principal, to the Java side. So we can rely on AJP to do the authentication, and just treat as unauthenticated any that come through without a Principal. There is a little risk here if a system is misconfigured that someone could talk directly to AJP, so we should look into securing the connection between Apache and Tomcat. If we need to keep session information around in the Java side, we can either add our own Session cookie, or store it in the Apache session. Right now, the only need for that I've seen is CRSF Nonces, which are currently disabled due to how IPA talks to Dogtag. We should probably re-enable them incase if anyone wants to talk to the PKI server directly, and provide an exception for IPA to do the work it needs for requesting certificates On the Tomcat side, we would still do JNDI LDAP for getting the Subjects,just using the principal forwarded from AJP. > > On Tue, 2011-11-08 at 13:10 -0500, Adam Young wrote: >> One issue I have been looking at recently is how to integrate PKI and >> IPA at the auth level while keeping a clean separation. >> >> We can extract the authentication from the servlet code, so it is >> purely a matter of configuring the Tomcat instance Realm. >> >> I wrote up a Proof of concept for just doing pure LDAP using simple >> bind, which is not a bad starting point. >> >> http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ >> >> >> We want to continue this approach, but use a more secure authentication >> method. We won't be using basic auth, and we won't be using simple bind. >> >> There are two forms of authentication we want to support: Client >> Certificates and Kerberos. Certificates will work as they do now, and >> Kerberos will be for passing through user credentials from IPA, through >> HTTP to CS. In both cases, the data that backs it will be stored in >> the DS instance. >> >> Tomcat has a class classed a CombinedRealm: >> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm >> >> That might support stacking Certificate and Kerberos auth on top of >> each other. The Realm will then delegate to LDAP for extracting the Roles. >> >> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm >> >> Kerberos is typically done using a JAAS Realm. I have to admit I don't >> really like the fact that we have to modify the JVM startup to do so, it >> is not really that big of a deal. I was also not a fan of setting the >> Realm up as a single service ticket until Simo informed me that the >> Browser NEGOTIATE mechanism assumes that the Service ticket is going to >> be Named HTTP. This means that for Proxied implementations, to include >> IPA, we will have to share the Service Principal Identity with the >> Apache HTTPD server. >> >> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm >> >> However, once you start digging in, you will find that the solutions >> are suboptimal. It turns out that the Negotiate auth-method has only >> very recently been supported, and that is only on Tomcat7. >> >> The best resource I have found on the options for a custom realm is here: >> http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos >> and the most likely option >> http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule >> >> We really want a mix of the KRB5Login Module and the JNDIRealm. That >> seems to be what is described here: >> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html >> >> We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with >> Tomcat-7. >> >> I suspect that the CombinedRealm approach will not support falling back >> from one auth-method to another: I've been looking and have not see it >> specified that you can put multiple auth-method entries inside a >> login-config in the web.xml. Ideally, we would attempt a Certificate >> based authentication first, and then fall back to Negotiate. However, >> we can say that a given deployment is going to be either Kerberos or >> Client Certificate, and swap out the configuration at the Tomcat >> level. I don't like that nearly as much. >> >> The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback >> talks about how to do Client Cert with a fallback to Form based >> authentication. We'd want to do Client Cert with a fallback to Krb5. >> This is using what is called a Valve. In Tomcat 6 and 7 valves have >> been deprecated in favor of Filters. The general approach is the same. >> >> I'd like to keep the idea of the Realm as the primary approach. If we >> do have to build a custom Realm, and I suspect that we will, we might >> want to spin it off into its own package, or submit it for Inclusion in >> Tomcat 7 upstream. >> >> It seems that the PKI approach has been to Bind as Directory Manager. >> What I would like to target moving forward is that the Bind is done as >> the user making the web request. For managed operations that require a >> higher level of authentication, we use the concept of queues like we do >> now. The threads that manage those queue will use a Principal with a >> higher level of authorization: not "Directory Manger", but perhaps "CA >> Manager" which is a user we create that manages the CA subtree in the >> Directory server. For a Dogtag deployment without IPA, the CA Manger >> would have write privileged on the Identity subtree. For integrated >> deployments, IPA would have its own principal "IPA Manager" that >> would not have read or write capabilities in the CA Subtree. DRM, >> TKS and other subsytems would in turn also get their own Manager users, >> and they would only have permissions to manage their own trees: we will >> need to clear up which gets read and write permissions on which other >> subtrees. >> >> Directory Manager would be limited to performing operations that effect >> the entire DS instance: Setup and Replication. >> >> The Directory Manager, CA Manager, IPA manager users should be binding >> with a certificate or a keytab, not with a cleartext password. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel From ayoung at redhat.com Fri Dec 2 15:39:44 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 10:39:44 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <1322770255.19378.52.camel@aleeredhat.laptop> References: <1322770255.19378.52.camel@aleeredhat.laptop> Message-ID: <4ED8F140.4060104@redhat.com> On 12/01/2011 03:10 PM, Ade Lee wrote: > Code formatting rules to be used in Eclipse for formatting once current > patches are checked in. > > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 15:40:30 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 10:40:30 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0001-Code-formatting-rules-for-the-Java-files.patch In-Reply-To: <1322770255.19378.52.camel@aleeredhat.laptop> References: <1322770255.19378.52.camel@aleeredhat.laptop> Message-ID: <4ED8F16E.5030301@redhat.com> On 12/01/2011 03:10 PM, Ade Lee wrote: > Code formatting rules to be used in Eclipse for formatting once current > patches are checked in. > > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Pushed to master in the git repo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 15:50:35 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 10:50:35 -0500 Subject: [Pki-devel] [PATCH] 0013-unnecessary-block-removal In-Reply-To: <4EBC3393.8000102@redhat.com> References: <4EBC3393.8000102@redhat.com> Message-ID: <4ED8F3CB.1090908@redhat.com> On 11/10/2011 03:26 PM, Adam Young wrote: > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACKed by Ade Lee. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at younglogic.com Fri Dec 2 17:19:57 2011 From: adam at younglogic.com (Adam) Date: Fri, 02 Dec 2011 12:19:57 -0500 Subject: [Pki-devel] Serial Version ID and Serializaed classes Message-ID: <4ED908BD.1000505@younglogic.com> Eclipse produces a hefty number of wranings about SerialVersionID. I think that we can safely be rid of them by accepting the autogenerated ID. Here's what this implies: If we ever use one of these classes in a serailzed manner where we don't control both sides of the connection, we have to make sure that the deserializer can read the persisted form. There are Two main cases: serialize to a file, serialize across a socket, For now, the only case where we serialize is in the case of a session failover. This is pretty much a non-issue, as the serialization is done betwen two version of the code that are identical. Actually, we don't even really support session failover ,but we could in theory support it. Serialization to a file is not done, nor has it ever really bee n a good idea. Typcially, file formats should be human readable. Serialization to a socket is primarily done in RMI. We aren't planning on supporting that. Still, it pays to be careful. So, here's the deal. We take the autogenerated ID, and that makes sure that only versions that match the serial version ID can read the file/socket. If we change areound the order of the member variables, change their types, add in new memebers, etc, we will need to regenerate the SerialVersionID to make sure that it doesn't give some wierd errors. I think that this will be caught by code reviews, so long as people are attuned. So, to sum up: get rid of the warning the "right" way, it is unlikely to be a problem regardless, but lets be careful in code reviews. Does this work for everyone? IF so, I'll create a patch. From nkinder at redhat.com Fri Dec 2 18:03:51 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 02 Dec 2011 10:03:51 -0800 Subject: [Pki-devel] [PATCH] 0014-Adjust-classpath-for-F16 In-Reply-To: <4EBC33C3.6020606@redhat.com> References: <4EBC33C3.6020606@redhat.com> Message-ID: <4ED91307.1090900@redhat.com> On 11/10/2011 12:27 PM, Adam Young wrote: > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK! I can build on f16 in Eclipse with no errors now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 18:19:50 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 13:19:50 -0500 Subject: [Pki-devel] [PATCH] 0014-Adjust-classpath-for-F16 In-Reply-To: <4ED91307.1090900@redhat.com> References: <4EBC33C3.6020606@redhat.com> <4ED91307.1090900@redhat.com> Message-ID: <4ED916C6.4010603@redhat.com> On 12/02/2011 01:03 PM, Nathan Kinder wrote: > On 11/10/2011 12:27 PM, Adam Young wrote: >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > ACK! I can build on f16 in Eclipse with no errors now. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 18:52:30 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 13:52:30 -0500 Subject: [Pki-devel] [PATCH] admiyo-0020-SerialVersionID Message-ID: <4ED91E6E.8050504@redhat.com> Removes the warning in Serializable classes. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0020-SerialVersionID.patch URL: From nkinder at redhat.com Fri Dec 2 19:29:40 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 02 Dec 2011 11:29:40 -0800 Subject: [Pki-devel] [PATCH] admiyo-0020-SerialVersionID In-Reply-To: <4ED91E6E.8050504@redhat.com> References: <4ED91E6E.8050504@redhat.com> Message-ID: <4ED92724.8020907@redhat.com> On 12/02/2011 10:52 AM, Adam Young wrote: > Removes the warning in Serializable classes. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK if you remove the whitespace errors. This patch cleaned up 333 build warnings for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 20:02:07 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 15:02:07 -0500 Subject: [Pki-devel] [PATCH] 0021-Remove-Deprecated-Date-Functions Message-ID: <4ED92EBF.2060907@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0021-Remove-Deprecated-Date-Functions.patch URL: From ayoung at redhat.com Fri Dec 2 20:50:17 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 15:50:17 -0500 Subject: [Pki-devel] [PATCH] admiyo-0020-SerialVersionID In-Reply-To: <4ED92724.8020907@redhat.com> References: <4ED91E6E.8050504@redhat.com> <4ED92724.8020907@redhat.com> Message-ID: <4ED93A09.2050006@redhat.com> On 12/02/2011 02:29 PM, Nathan Kinder wrote: > On 12/02/2011 10:52 AM, Adam Young wrote: >> Removes the warning in Serializable classes. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > ACK if you remove the whitespace errors. This patch cleaned up 333 > build warnings for me. Applied with: git am --whitespace=fix and Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 2 22:03:59 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 17:03:59 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically In-Reply-To: <4EC13843.7080103@redhat.com> References: <4EBC96F2.4080101@redhat.com> <4EC13843.7080103@redhat.com> Message-ID: <4ED94B4F.4030300@redhat.com> On 11/14/2011 10:48 AM, Adam Young wrote: > On 11/10/2011 10:30 PM, Adam Young wrote: >> >> _______________________________________________ >> 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 Rebased on top of the current master -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0017-1-call-statics-statically.patch URL: From ayoung at redhat.com Fri Dec 2 22:27:50 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 17:27:50 -0500 Subject: [Pki-devel] [PATCH] 0021-Remove-Deprecated-Date-Functions In-Reply-To: <4ED92EBF.2060907@redhat.com> References: <4ED92EBF.2060907@redhat.com> Message-ID: <4ED950E6.4090109@redhat.com> On 12/02/2011 03:02 PM, Adam Young wrote: > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel This was commited by accident and then Reverted. It will be resubmited with Unit tests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Fri Dec 2 23:33:13 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 02 Dec 2011 15:33:13 -0800 Subject: [Pki-devel] [PATCH] Bug 757848 - fixes sporadic blank line in DRMTool Message-ID: <4ED96039.5060505@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pki-mharmsen-0000-Bug-757848-fixes-sporadic-blank-line-in-DRMTool.patch URL: From awnuk at redhat.com Fri Dec 2 23:33:37 2011 From: awnuk at redhat.com (Andrew Wnuk) Date: Fri, 02 Dec 2011 15:33:37 -0800 Subject: [Pki-devel] [PATCH] Bug 757848 - fixes sporadic blank line in DRMTool In-Reply-To: <4ED96039.5060505@redhat.com> References: <4ED96039.5060505@redhat.com> Message-ID: <4ED96051.80306@redhat.com> On 12/02/2011 03:33 PM, Matthew Harmsen wrote: > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Fri Dec 2 23:46:34 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 02 Dec 2011 15:46:34 -0800 Subject: [Pki-devel] [PATCH] Bug 759339 - fixes sporadic blank line in DRMTool Message-ID: <4ED9635A.608@redhat.com> Revised Bug #. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pki-mharmsen-0000-Bug-759339-fixes-sporadic-blank-line-in-DRMTool.patch URL: From ayoung at redhat.com Sun Dec 4 02:31:02 2011 From: ayoung at redhat.com (Adam Young) Date: Sat, 03 Dec 2011 21:31:02 -0500 Subject: [Pki-devel] [PATCH] Bug 759339 - fixes sporadic blank line in DRMTool In-Reply-To: <4ED9635A.608@redhat.com> References: <4ED9635A.608@redhat.com> Message-ID: <4EDADB66.50709@redhat.com> On 12/02/2011 06:46 PM, Matthew Harmsen wrote: > Revised Bug #. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel I don't know the code well enough to understand why this makes sense. Is it right to replace \\s+$ everywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Dec 5 04:42:46 2011 From: alee at redhat.com (Ade Lee) Date: Sun, 04 Dec 2011 23:42:46 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically In-Reply-To: <4ED94B4F.4030300@redhat.com> References: <4EBC96F2.4080101@redhat.com> <4EC13843.7080103@redhat.com> <4ED94B4F.4030300@redhat.com> Message-ID: <1323060167.19378.55.camel@aleeredhat.laptop> This patch does not apply cleanly for me on the new repo. Does it apply for anyone else? Ade On Fri, 2011-12-02 at 17:03 -0500, Adam Young wrote: > On 11/14/2011 10:48 AM, Adam Young wrote: > > On 11/10/2011 10:30 PM, Adam Young wrote: > > > > > > _______________________________________________ > > > 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 > Rebased on top of the current master > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From simo at redhat.com Fri Dec 2 03:04:36 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 22:04:36 -0500 Subject: [Pki-devel] [Freeipa-devel] Tomcat Realms and Directory Server In-Reply-To: <4EB970AB.9080807@redhat.com> References: <4EB970AB.9080807@redhat.com> Message-ID: <1322795076.22044.68.camel@willson.li.ssimo.org> Hi Adam, I haven't replied to this summary so far for 2 reasons. I had little time to ponder it (and Java is not my forte) and it is still a bit up in the air. I am a bit concerned about the relatively unstable/young support for some of the tech that would have to be involved, but on the other hand I tend to like the approach of better in depth security, auth forwarding, and isolation of instances and credentials used. I think you should keep exploring this area and see what works and what not. I wonder if the session work we are doing for the main IPA framework can be used in some way to simplify part of the work you are doing. Unfortunately working in Java may be an obstacle in this sense as we plan to use python native marchalling/unmarshalling of objects in the session cache, but keep in mind this may be an avenue to offload most of the auth/session management work to the IPA framework and simplify your credential management at least when dogtag is integrated with IPA. Simo. On Tue, 2011-11-08 at 13:10 -0500, Adam Young wrote: > One issue I have been looking at recently is how to integrate PKI and > IPA at the auth level while keeping a clean separation. > > We can extract the authentication from the servlet code, so it is > purely a matter of configuring the Tomcat instance Realm. > > I wrote up a Proof of concept for just doing pure LDAP using simple > bind, which is not a bad starting point. > > http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ > > > We want to continue this approach, but use a more secure authentication > method. We won't be using basic auth, and we won't be using simple bind. > > There are two forms of authentication we want to support: Client > Certificates and Kerberos. Certificates will work as they do now, and > Kerberos will be for passing through user credentials from IPA, through > HTTP to CS. In both cases, the data that backs it will be stored in > the DS instance. > > Tomcat has a class classed a CombinedRealm: > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm > > That might support stacking Certificate and Kerberos auth on top of > each other. The Realm will then delegate to LDAP for extracting the Roles. > > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm > > Kerberos is typically done using a JAAS Realm. I have to admit I don't > really like the fact that we have to modify the JVM startup to do so, it > is not really that big of a deal. I was also not a fan of setting the > Realm up as a single service ticket until Simo informed me that the > Browser NEGOTIATE mechanism assumes that the Service ticket is going to > be Named HTTP. This means that for Proxied implementations, to include > IPA, we will have to share the Service Principal Identity with the > Apache HTTPD server. > > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm > > However, once you start digging in, you will find that the solutions > are suboptimal. It turns out that the Negotiate auth-method has only > very recently been supported, and that is only on Tomcat7. > > The best resource I have found on the options for a custom realm is here: > http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos > and the most likely option > http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule > > We really want a mix of the KRB5Login Module and the JNDIRealm. That > seems to be what is described here: > http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html > > We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with > Tomcat-7. > > I suspect that the CombinedRealm approach will not support falling back > from one auth-method to another: I've been looking and have not see it > specified that you can put multiple auth-method entries inside a > login-config in the web.xml. Ideally, we would attempt a Certificate > based authentication first, and then fall back to Negotiate. However, > we can say that a given deployment is going to be either Kerberos or > Client Certificate, and swap out the configuration at the Tomcat > level. I don't like that nearly as much. > > The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback > talks about how to do Client Cert with a fallback to Form based > authentication. We'd want to do Client Cert with a fallback to Krb5. > This is using what is called a Valve. In Tomcat 6 and 7 valves have > been deprecated in favor of Filters. The general approach is the same. > > I'd like to keep the idea of the Realm as the primary approach. If we > do have to build a custom Realm, and I suspect that we will, we might > want to spin it off into its own package, or submit it for Inclusion in > Tomcat 7 upstream. > > It seems that the PKI approach has been to Bind as Directory Manager. > What I would like to target moving forward is that the Bind is done as > the user making the web request. For managed operations that require a > higher level of authentication, we use the concept of queues like we do > now. The threads that manage those queue will use a Principal with a > higher level of authorization: not "Directory Manger", but perhaps "CA > Manager" which is a user we create that manages the CA subtree in the > Directory server. For a Dogtag deployment without IPA, the CA Manger > would have write privileged on the Identity subtree. For integrated > deployments, IPA would have its own principal "IPA Manager" that > would not have read or write capabilities in the CA Subtree. DRM, > TKS and other subsytems would in turn also get their own Manager users, > and they would only have permissions to manage their own trees: we will > need to clear up which gets read and write permissions on which other > subtrees. > > Directory Manager would be limited to performing operations that effect > the entire DS instance: Setup and Replication. > > The Directory Manager, CA Manager, IPA manager users should be binding > with a certificate or a keytab, not with a cleartext password. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Mon Dec 5 15:19:59 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 10:19:59 -0500 Subject: [Pki-devel] [PATCH] 0021-Remove-Deprecated-Date-Functions In-Reply-To: <4ED950E6.4090109@redhat.com> References: <4ED92EBF.2060907@redhat.com> <4ED950E6.4090109@redhat.com> Message-ID: <4EDCE11F.1020502@redhat.com> Found a parsing error. This is the output that confirms that the code still works: old start = 934948800000 new start = 934985539332 differenceDays = 0 old end = 1337659200000 new end = 1337695939332 differenceDays = 0 instance Name old:R20111105101219 instance Name new:R20111105101219 date to z old:20111205101219Z date to z new:20111205101219Z old = 1021569630000 new = 1021569630334 old = 1021569630000 new = 1021569630334 Attached are the two files that produce that output; -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0021-1-Remove-Deprecated-Date-Functions.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DateRange.java Type: text/x-java Size: 180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestDateWork.java Type: text/x-java Size: 6707 bytes Desc: not available URL: From dbhole at redhat.com Mon Dec 5 16:31:10 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 5 Dec 2011 11:31:10 -0500 Subject: [Pki-devel] [fedora-java] CMake 'JNI' macro question . . . In-Reply-To: <4ED65172.603@redhat.com> References: <4ED59AA9.1000805@redhat.com> <4ED65172.603@redhat.com> Message-ID: <20111205163056.GD8668@redhat.com> * Adam Young [2011-11-30 10:53]: > Cross posting to the Java Devel list > On 11/29/2011 09:53 PM, Matthew Harmsen wrote: > > Andreas, > I would like to request your assistance on the following 'CMake' issue > requested by Adam: > * [1]https://fedorahosted.org/pki/ticket/9 > The jnidir macro is statically set to ../lib/: %_jnidir %{_prefix}/lib/java This is unlikely to change in the near future. Please see this bug for more info: https://bugzilla.redhat.com/show_bug.cgi?id=665576 The top comments (2,3,4,...) would be of interest. Cheers, Deepak From dbhole at redhat.com Mon Dec 5 16:51:17 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 5 Dec 2011 11:51:17 -0500 Subject: [Pki-devel] [fedora-java] CMake 'JNI' macro question . . . In-Reply-To: <20111205163056.GD8668@redhat.com> References: <4ED59AA9.1000805@redhat.com> <4ED65172.603@redhat.com> <20111205163056.GD8668@redhat.com> Message-ID: <20111205165117.GE8668@redhat.com> * Deepak Bhole [2011-12-05 11:31]: > * Adam Young [2011-11-30 10:53]: > > Cross posting to the Java Devel list > > On 11/29/2011 09:53 PM, Matthew Harmsen wrote: > > > > Andreas, > > I would like to request your assistance on the following 'CMake' issue > > requested by Adam: > > * [1]https://fedorahosted.org/pki/ticket/9 > > > > The jnidir macro is statically set to ../lib/: > %_jnidir %{_prefix}/lib/java > > This is unlikely to change in the near future. Please see this bug for > more info: > https://bugzilla.redhat.com/show_bug.cgi?id=665576 > > The top comments (2,3,4,...) would be of interest. > Doh. Stano just informed me that this has been changed on F16 afterall (my system is F15): https://bugzilla.redhat.com/show_bug.cgi?id=665576#c38 Sorry for the confusion. Deepak From mharmsen at redhat.com Mon Dec 5 16:51:21 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 05 Dec 2011 08:51:21 -0800 Subject: [Pki-devel] [fedora-java] CMake 'JNI' macro question . . . In-Reply-To: <20111205163056.GD8668@redhat.com> References: <4ED59AA9.1000805@redhat.com> <4ED65172.603@redhat.com> <20111205163056.GD8668@redhat.com> Message-ID: <4EDCF689.1050003@redhat.com> On 12/05/11 08:31, Deepak Bhole wrote: > * Adam Young [2011-11-30 10:53]: >> Cross posting to the Java Devel list >> On 11/29/2011 09:53 PM, Matthew Harmsen wrote: >> >> Andreas, >> I would like to request your assistance on the following 'CMake' issue >> requested by Adam: >> * [1]https://fedorahosted.org/pki/ticket/9 >> > The jnidir macro is statically set to ../lib/: > %_jnidir %{_prefix}/lib/java Deepak, This was true in Fedora 15 and earlier as well as RHEL 6 and earlier. However, see https://bugzilla.redhat.com/show_bug.cgi?id=665576#c38, in which Stanislav Ochotnicky changed the definition of '%_jnidir' on 7/4/2011 to: * %_jnidir is now %_libdir/java This change appears to have been applied to Fedora 16 and later. -- Matt > This is unlikely to change in the near future. Please see this bug for > more info: > https://bugzilla.redhat.com/show_bug.cgi?id=665576 > > The top comments (2,3,4,...) would be of interest. > > Cheers, > Deepak > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Mon Dec 5 17:09:49 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 05 Dec 2011 09:09:49 -0800 Subject: [Pki-devel] [PATCH] Bug 759339 - fixes sporadic blank line in DRMTool In-Reply-To: <4EDADB66.50709@redhat.com> References: <4ED9635A.608@redhat.com> <4EDADB66.50709@redhat.com> Message-ID: <4EDCFADD.3030201@redhat.com> On 12/03/11 18:31, Adam Young wrote: > On 12/02/2011 06:46 PM, Matthew Harmsen wrote: >> Revised Bug #. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > I don't know the code well enough to understand why this makes sense. > > > Is it right to replace \\s+$ everywhere? Yes. This is a fix to a corner-case that was discovered during RHCS 8.1 Q/E testing. The method where this change is implemented is in constructing a multi-line entry (which contain embedded NEWLINES) as a part of an LDIF record, and is called by entries that require this type of formatting. This strips all white-space at the end of the value returned; any white-space at the beginning of each line of a value must be maintained. Each final LDIF entry (single as well as multi-line entry) is output as (entry + NEWLINE), and thus the corner case that exposed this flaw contained an entry that had been terminated with a NEWLINE causing a blank line to be interjected into the LDIF record. This fix has been tested by development, and will be further tested by Q/E during RHCS 8.1 testing. -- Matt > > > _______________________________________________ > 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 ayoung at redhat.com Mon Dec 5 19:38:51 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 14:38:51 -0500 Subject: [Pki-devel] [PATCH] 2 Added JUnit report generator. In-Reply-To: <4ED7E097.609@redhat.com> References: <4ED79C0B.6060708@redhat.com> <4ED7D03F.9040907@redhat.com> <4ED7D216.6050401@redhat.com> <4ED7E097.609@redhat.com> Message-ID: <4EDD1DCB.50607@redhat.com> On 12/01/2011 03:16 PM, Endi Sukma Dewata wrote: > On 12/1/2011 1:14 PM, Adam Young wrote: >>> Runs fine the first time, but you can't run the test twice. >>> >>> [ayoung at ayoung core]$ make test >>> mkdir: cannot create directory `reports': File exists >>> make[3]: *** [base/common/test/CMakeFiles/test-pki-common] Error 1 >>> make[2]: *** [base/common/test/CMakeFiles/test-pki-common.dir/all] >>> Error 2 >>> make[1]: *** [CMakeFiles/test.dir/rule] Error 2 >>> make: *** [test] Error 2 >>> >>> Do mkdir -p instead > > Fixed in the new patch. > >> Also, the recompile doesn't seem to be getting triggered. I added a >> fail(); to a test .java file to trigger an exception, and nothing >> happened, then I ran make all and the make test and saw the stack trace. >> REmoving it, same thing. > > Yes, I've put "TODO: build test only when the test is invoked". Right > now the test files are only compiled under "all" target, it should > have been under "test" target. I'm still not sure how to call > add_jar() from a custom target. The add_custom_command() let's you add > a command but not a function invocation. Maybe the whole common/test > should be called under "test" too. > ACK From ayoung at redhat.com Mon Dec 5 22:46:12 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 17:46:12 -0500 Subject: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes In-Reply-To: <4EC478BC.4070600@redhat.com> References: <4EC478BC.4070600@redhat.com> Message-ID: <4EDD49B4.9060103@redhat.com> On 11/16/2011 10:00 PM, Adam Young wrote: > Tested by running ipa-server-install, which calls pkisilent. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Rebased -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0019-1-PKISilent-type-safety-changes.patch URL: From ayoung at redhat.com Mon Dec 5 22:57:28 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 17:57:28 -0500 Subject: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes In-Reply-To: <4EDD49B4.9060103@redhat.com> References: <4EC478BC.4070600@redhat.com> <4EDD49B4.9060103@redhat.com> Message-ID: <4EDD4C58.80802@redhat.com> On 12/05/2011 05:46 PM, Adam Young wrote: > On 11/16/2011 10:00 PM, Adam Young wrote: >> Tested by running ipa-server-install, which calls pkisilent. >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Rebased > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Last one accidentally picked up some patch artifacts it should not have. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0019-2-PKISilent-type-safety-changes.patch URL: From jmagne at redhat.com Tue Dec 6 00:57:40 2011 From: jmagne at redhat.com (John Magne) Date: Mon, 05 Dec 2011 19:57:40 -0500 (EST) Subject: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes In-Reply-To: <4EDD4C58.80802@redhat.com> Message-ID: ----- Original Message ----- From: "Adam Young" To: pki-devel at redhat.com Sent: Monday, December 5, 2011 2:57:28 PM Subject: Re: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes On 12/05/2011 05:46 PM, Adam Young wrote: On 11/16/2011 10:00 PM, Adam Young wrote: Tested by running ipa-server-install, which calls pkisilent. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel Rebased _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel Last one accidentally picked up some patch artifacts it should not have. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel ACK! Patch looks good and compiles for me in Eclipse: When I tried to apply it though I got this after removing the "<" from the file. Applying: PKISilent type safety changes /home/jmagne/pki-git-test/pki/.git/rebase-apply/patch:817: trailing whitespace. defaultHelpOption = firstHelpOption = matchList.get(0); /home/jmagne/pki-git-test/pki/.git/rebase-apply/patch:861: trailing whitespace. { ((Vector)rec.resHolder).add (result); warning: 2 lines add whitespace errors. If this is a non-issue, go ahead. From ayoung at redhat.com Tue Dec 6 01:14:25 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 20:14:25 -0500 Subject: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes In-Reply-To: References: Message-ID: <4EDD6C71.8090802@redhat.com> On 12/05/2011 07:57 PM, John Magne wrote: > > ----- Original Message ----- > From: "Adam Young" > To: pki-devel at redhat.com > Sent: Monday, December 5, 2011 2:57:28 PM > Subject: Re: [Pki-devel] [PATCH] 0019-PKISilent-type-safety-changes > > > On 12/05/2011 05:46 PM, Adam Young wrote: > > On 11/16/2011 10:00 PM, Adam Young wrote: > > > Tested by running ipa-server-install, which calls pkisilent. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > Rebased > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel > Last one accidentally picked up some patch artifacts it should not have. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > ACK! > > Patch looks good and compiles for me in Eclipse: > > When I tried to apply it though I got this after removing the "<" from the file. > > Applying: PKISilent type safety changes > /home/jmagne/pki-git-test/pki/.git/rebase-apply/patch:817: trailing whitespace. > defaultHelpOption = firstHelpOption = matchList.get(0); > /home/jmagne/pki-git-test/pki/.git/rebase-apply/patch:861: trailing whitespace. > { ((Vector)rec.resHolder).add (result); > warning: 2 lines add whitespace errors. > > If this is a non-issue, go ahead. > pushed to master. From ayoung at redhat.com Tue Dec 6 01:24:59 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 20:24:59 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet Message-ID: <4EDD6EEB.4020406@redhat.com> More type safety cleanup. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0022-TreeSet.patch URL: From alee at redhat.com Tue Dec 6 03:41:00 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 05 Dec 2011 22:41:00 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically In-Reply-To: <1323060167.19378.55.camel@aleeredhat.laptop> References: <4EBC96F2.4080101@redhat.com> <4EC13843.7080103@redhat.com> <4ED94B4F.4030300@redhat.com> <1323060167.19378.55.camel@aleeredhat.laptop> Message-ID: <1323142861.19378.63.camel@aleeredhat.laptop> pki/base/common/src/com/netscape/cms/logging/LogFile.java : -- remove unused variable logStatus and logSigning OCSPServlet.java - remove unused variable urldecoder CryptoUtil.java: remove unused variable sigAlgId this will also remove a deprecation. GenericASN1Extension.java : this just looks wrong PKCS8Key.java : same thing here Ade On Sun, 2011-12-04 at 23:42 -0500, Ade Lee wrote: > This patch does not apply cleanly for me on the new repo. > > Does it apply for anyone else? > Ade > > On Fri, 2011-12-02 at 17:03 -0500, Adam Young wrote: > > On 11/14/2011 10:48 AM, Adam Young wrote: > > > On 11/10/2011 10:30 PM, Adam Young wrote: > > > > > > > > _______________________________________________ > > > > 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 > > Rebased on top of the current master > > _______________________________________________ > > 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 Tue Dec 6 04:19:07 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 05 Dec 2011 23:19:07 -0500 Subject: [Pki-devel] [PATCH] 0021-Remove-Deprecated-Date-Functions In-Reply-To: <4EDCE11F.1020502@redhat.com> References: <4ED92EBF.2060907@redhat.com> <4ED950E6.4090109@redhat.com> <4EDCE11F.1020502@redhat.com> Message-ID: <1323145148.19378.66.camel@aleeredhat.laptop> Adam, Maybe I'm missing something here, but why is it that : old start != new start old_end != new end old != new and shouldn't they be equal? Ade On Mon, 2011-12-05 at 10:19 -0500, Adam Young wrote: > Found a parsing error. > > > This is the output that confirms that the code still works: > > old start = 934948800000 > new start = 934985539332 > differenceDays = 0 > old end = 1337659200000 > new end = 1337695939332 > differenceDays = 0 > instance Name old:R20111105101219 > instance Name new:R20111105101219 > date to z old:20111205101219Z > date to z new:20111205101219Z > old = 1021569630000 > new = 1021569630334 > old = 1021569630000 > new = 1021569630334 > > > Attached are the two files that produce that output; > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Tue Dec 6 15:21:41 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Dec 2011 10:21:41 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically In-Reply-To: <1323142861.19378.63.camel@aleeredhat.laptop> References: <4EBC96F2.4080101@redhat.com> <4EC13843.7080103@redhat.com> <4ED94B4F.4030300@redhat.com> <1323060167.19378.55.camel@aleeredhat.laptop> <1323142861.19378.63.camel@aleeredhat.laptop> Message-ID: <4EDE3305.7030302@redhat.com> On 12/05/2011 10:41 PM, Ade Lee wrote: > pki/base/common/src/com/netscape/cms/logging/LogFile.java : > -- remove unused variable logStatus and logSigning > > OCSPServlet.java - remove unused variable urldecoder > > CryptoUtil.java: remove unused variable sigAlgId > this will also remove a deprecation. > > GenericASN1Extension.java : this just looks wrong I agree it looks wrong, but the change is actually in keeping with haw the pattern vairable was used. I think the mistake is that pattern should not be static. Changing it from static to private does not bring in any compilation warnings but that constructror in general looks wrong NAME = name; OID = oid; mConfig = config; those are all statics. the problem is, I think, with the NAME field. I was digging through that during the Generics cleanup and here's what I think is supposed to happen: for most extensions, they use the name as a static field for al ook up: crete a new instance of this kind of class for that extension, the vast majority of them have NAME match the classname...some with the word extension, some without. GenericASN1Extension does not work that way. Generic is defined at run time, so this implementation says to me that there can really only ever be one extension defined, but nothing ever enfroces that so I think that this change, while weird, is strictly speaking correct. I suggest we make the change, and open a ticket to deal with the Statics in this class. > PKCS8Key.java : same thing here Here the static is a key used, and should be a constant 0. Changing it to the proper naming convention. Updated patch attached. > > Ade > > > > On Sun, 2011-12-04 at 23:42 -0500, Ade Lee wrote: >> This patch does not apply cleanly for me on the new repo. >> >> Does it apply for anyone else? >> Ade >> >> On Fri, 2011-12-02 at 17:03 -0500, Adam Young wrote: >>> On 11/14/2011 10:48 AM, Adam Young wrote: >>>> On 11/10/2011 10:30 PM, Adam Young wrote: >>>>> _______________________________________________ >>>>> 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 >>> Rebased on top of the current master >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0017-2-call-statics-statically.patch URL: From ayoung at redhat.com Tue Dec 6 15:23:08 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Dec 2011 10:23:08 -0500 Subject: [Pki-devel] [PATCH] 0021-Remove-Deprecated-Date-Functions In-Reply-To: <1323145148.19378.66.camel@aleeredhat.laptop> References: <4ED92EBF.2060907@redhat.com> <4ED950E6.4090109@redhat.com> <4EDCE11F.1020502@redhat.com> <1323145148.19378.66.camel@aleeredhat.laptop> Message-ID: <4EDE335C.7080205@redhat.com> On 12/05/2011 11:19 PM, Ade Lee wrote: > Adam, > > Maybe I'm missing something here, but why is it that : > old start != new start > old_end != new end > old != new Because they only define the time down to the day, and it is stored as miliseconds, so the least significant bits are meaningless. Hence: differenceDays = 0 is the real test. I just tried to show my work how I got there. > > and shouldn't they be equal? > > Ade > > On Mon, 2011-12-05 at 10:19 -0500, Adam Young wrote: >> Found a parsing error. >> >> >> This is the output that confirms that the code still works: >> >> old start = 934948800000 >> new start = 934985539332 >> differenceDays = 0 >> old end = 1337659200000 >> new end = 1337695939332 >> differenceDays = 0 >> instance Name old:R20111105101219 >> instance Name new:R20111105101219 >> date to z old:20111205101219Z >> date to z new:20111205101219Z >> old = 1021569630000 >> new = 1021569630334 >> old = 1021569630000 >> new = 1021569630334 >> >> >> Attached are the two files that produce that output; >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > From alee at redhat.com Tue Dec 6 16:00:18 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 06 Dec 2011 11:00:18 -0500 Subject: [Pki-devel] [PATCH] 0021-Remove-Deprecated-Date-Functions In-Reply-To: <4EDE335C.7080205@redhat.com> References: <4ED92EBF.2060907@redhat.com> <4ED950E6.4090109@redhat.com> <4EDCE11F.1020502@redhat.com> <1323145148.19378.66.camel@aleeredhat.laptop> <4EDE335C.7080205@redhat.com> Message-ID: <1323187219.19378.67.camel@aleeredhat.laptop> Ok, based on conversation with Adam. ACK On Tue, 2011-12-06 at 10:23 -0500, Adam Young wrote: > On 12/05/2011 11:19 PM, Ade Lee wrote: > > Adam, > > > > Maybe I'm missing something here, but why is it that : > > old start != new start > > old_end != new end > > old != new > > Because they only define the time down to the day, and it is stored as > miliseconds, so the least significant bits are meaningless. Hence: > > differenceDays = 0 > > is the real test. I just tried to show my work how I got there. > > > > > and shouldn't they be equal? > > > > Ade > > > > On Mon, 2011-12-05 at 10:19 -0500, Adam Young wrote: > >> Found a parsing error. > >> > >> > >> This is the output that confirms that the code still works: > >> > >> old start = 934948800000 > >> new start = 934985539332 > >> differenceDays = 0 > >> old end = 1337659200000 > >> new end = 1337695939332 > >> differenceDays = 0 > >> instance Name old:R20111105101219 > >> instance Name new:R20111105101219 > >> date to z old:20111205101219Z > >> date to z new:20111205101219Z > >> old = 1021569630000 > >> new = 1021569630334 > >> old = 1021569630000 > >> new = 1021569630334 > >> > >> > >> Attached are the two files that produce that output; > >> _______________________________________________ > >> Pki-devel mailing list > >> Pki-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/pki-devel > > > From ayoung at redhat.com Tue Dec 6 16:22:45 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Dec 2011 11:22:45 -0500 Subject: [Pki-devel] [PATCH] 0017-call-statics-statically In-Reply-To: <4EDE3305.7030302@redhat.com> References: <4EBC96F2.4080101@redhat.com> <4EC13843.7080103@redhat.com> <4ED94B4F.4030300@redhat.com> <1323060167.19378.55.camel@aleeredhat.laptop> <1323142861.19378.63.camel@aleeredhat.laptop> <4EDE3305.7030302@redhat.com> Message-ID: <4EDE4155.5080303@redhat.com> On 12/06/2011 10:21 AM, Adam Young wrote: > On 12/05/2011 10:41 PM, Ade Lee wrote: >> pki/base/common/src/com/netscape/cms/logging/LogFile.java : >> -- remove unused variable logStatus and logSigning >> >> OCSPServlet.java - remove unused variable urldecoder >> >> CryptoUtil.java: remove unused variable sigAlgId >> this will also remove a deprecation. >> >> GenericASN1Extension.java : this just looks wrong > > > I agree it looks wrong, but the change is actually in keeping with > haw the pattern vairable was used. I think the mistake is that > pattern should not be static. > Changing it from static to private does not bring in any compilation > warnings > but that constructror in general looks wrong > NAME = name; > OID = oid; > mConfig = config; > those are all statics. > the problem is, I think, with the NAME field. I was digging through > that during the Generics cleanup and here's what I think is supposed > to happen: for most extensions, they use the name as a static field > for al ook up: crete a new instance of this kind of class for that > extension, the vast majority of them have NAME match the > classname...some with the word extension, some without. > > GenericASN1Extension does not work that way. Generic is defined at > run time, so this implementation says to me that there can really > only ever be one extension defined, but nothing ever enfroces that > so I think that this change, while weird, is strictly speaking > correct. I suggest we make the change, and open a ticket to deal > with the Statics in this class. Reverted to leave the warning in based on our phone conversation. > >> PKCS8Key.java : same thing here > > Here the static is a key used, and should be a constant 0. Changing > it to the proper naming convention. > > > > Updated patch attached. > >> >> Ade >> >> >> >> On Sun, 2011-12-04 at 23:42 -0500, Ade Lee wrote: >>> This patch does not apply cleanly for me on the new repo. >>> >>> Does it apply for anyone else? >>> Ade >>> >>> On Fri, 2011-12-02 at 17:03 -0500, Adam Young wrote: >>>> On 11/14/2011 10:48 AM, Adam Young wrote: >>>>> On 11/10/2011 10:30 PM, Adam Young wrote: >>>>>> _______________________________________________ >>>>>> 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 >>>> Rebased on top of the current master >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Reverted change in ASN1 Extension and Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0017-3-call-statics-statically.patch URL: From ayoung at redhat.com Wed Dec 7 03:10:59 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Dec 2011 22:10:59 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet In-Reply-To: <4EDD6EEB.4020406@redhat.com> References: <4EDD6EEB.4020406@redhat.com> Message-ID: <4EDED943.2070700@redhat.com> On 12/05/2011 08:24 PM, Adam Young wrote: > More type safety cleanup. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel There was some concern that replacing the clone method with a nother form of type safe copy would have performance implications. This version replaces the clone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0022-1-TreeSet.patch URL: From ayoung at redhat.com Wed Dec 7 03:17:34 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Dec 2011 22:17:34 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet In-Reply-To: <4EDED943.2070700@redhat.com> References: <4EDD6EEB.4020406@redhat.com> <4EDED943.2070700@redhat.com> Message-ID: <4EDEDACE.3080601@redhat.com> On 12/06/2011 10:10 PM, Adam Young wrote: > On 12/05/2011 08:24 PM, Adam Young wrote: >> More type safety cleanup. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > There was some concern that replacing the clone method with a nother > form of type safe copy would have performance implications. This > version replaces the clone. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Missed a couple changes in the last commit. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0022-2-TreeSet.patch URL: From ayoung at redhat.com Wed Dec 7 03:19:08 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Dec 2011 22:19:08 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet In-Reply-To: <4EDEDACE.3080601@redhat.com> References: <4EDD6EEB.4020406@redhat.com> <4EDED943.2070700@redhat.com> <4EDEDACE.3080601@redhat.com> Message-ID: <4EDEDB2C.7090402@redhat.com> On 12/06/2011 10:17 PM, Adam Young wrote: > On 12/06/2011 10:10 PM, Adam Young wrote: >> On 12/05/2011 08:24 PM, Adam Young wrote: >>> More type safety cleanup. >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> There was some concern that replacing the clone method with a nother >> form of type safe copy would have performance implications. This >> version replaces the clone. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Missed a couple changes in the last commit. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel And missed an @SupressError in it as well. as left in a stray paren. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0022-3-TreeSet.patch URL: From ayoung at redhat.com Wed Dec 7 16:07:52 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Dec 2011 11:07:52 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <4EC3D8E6.6080002@redhat.com> References: <4EBC96B4.1010700@redhat.com> <1321454906.3201.7.camel@aleeredhat.laptop> <4EC3D8E6.6080002@redhat.com> Message-ID: <4EDF8F58.5080708@redhat.com> On 11/16/2011 10:38 AM, Adam Young wrote: > On 11/16/2011 09:48 AM, Ade Lee wrote: >> I'm struggling with the premise behind this patch. Some of these >> methods seem like they are valuable - and certainly they were valuable >> at some point in time (or they would not have been written). On the >> other hand, I see the benefit of trimming the code base. No need to >> refactor code that isn't being used. >> >> I realize that this removes some eclipse warnings, but is removing these >> methods good practice? >> >> I guess I'm looking for some other folks to chime in here. > > My feeling is that you do not leave dead code in the code base. The > code still exists in the repository, but it is unlikely that a piece > of code that is not called today will be needed in exactly the same > form in the future. > > > Code is documentation. Code that is not used is misleading to the > maintainer. Committing commented out code is a bad practice. > > As we refactor, the location of the behavior of a lot of these > methods will change. Thus, some orphan calls will become uncallable, > and others will get in the way of code clean up. > > > This is old code: some of it goes back 15 years. Holding on to > unused, uncallable code is akin to hoarding. > > >> >> Ade >> >> On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: >>> _______________________________________________ >>> 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 Conflicted with the PKI Silent changes, so patch has been remade by hand. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0015-1-Removal-of-unused-private-methods.patch URL: From ayoung at redhat.com Wed Dec 7 16:46:26 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Dec 2011 11:46:26 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet In-Reply-To: <4EDEDB2C.7090402@redhat.com> References: <4EDD6EEB.4020406@redhat.com> <4EDED943.2070700@redhat.com> <4EDEDACE.3080601@redhat.com> <4EDEDB2C.7090402@redhat.com> Message-ID: <4EDF9862.9010202@redhat.com> On 12/06/2011 10:19 PM, Adam Young wrote: > On 12/06/2011 10:17 PM, Adam Young wrote: >> On 12/06/2011 10:10 PM, Adam Young wrote: >>> On 12/05/2011 08:24 PM, Adam Young wrote: >>>> More type safety cleanup. >>>> >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> >>> There was some concern that replacing the clone method with a nother >>> form of type safe copy would have performance implications. This >>> version replaces the clone. >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> Missed a couple changes in the last commit. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > And missed an @SupressError in it as well. as left in a stray paren. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel New version replaces some of the @Supress with catch blocks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dogtag-admiyo-0022-4-TreeSet.patch URL: From alee at redhat.com Wed Dec 7 18:34:07 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 07 Dec 2011 13:34:07 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet In-Reply-To: <4EDF9862.9010202@redhat.com> References: <4EDD6EEB.4020406@redhat.com> <4EDED943.2070700@redhat.com> <4EDEDACE.3080601@redhat.com> <4EDEDB2C.7090402@redhat.com> <4EDF9862.9010202@redhat.com> Message-ID: <1323282847.26127.1.camel@aleeredhat.laptop> The change we discussed on #dogtag-pki should be included. Specifically, alee, this works @SuppressWarnings("unchecked") Vector newProfileList = (Vector) profileList.clone(); mProfileList = newProfileList; Other than that, the patch looks good. Ade On Wed, 2011-12-07 at 11:46 -0500, Adam Young wrote: > On 12/06/2011 10:19 PM, Adam Young wrote: > > On 12/06/2011 10:17 PM, Adam Young wrote: > > > On 12/06/2011 10:10 PM, Adam Young wrote: > > > > On 12/05/2011 08:24 PM, Adam Young wrote: > > > > > More type safety cleanup. > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pki-devel mailing list > > > > > Pki-devel at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > There was some concern that replacing the clone method with a > > > > nother form of type safe copy would have performance > > > > implications. This version replaces the clone. > > > > > > > > > > > > _______________________________________________ > > > > Pki-devel mailing list > > > > Pki-devel at redhat.com > > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > Missed a couple changes in the last commit. > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > And missed an @SupressError in it as well. as left in a stray paren. > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > New version replaces some of the @Supress with catch blocks > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Wed Dec 7 18:59:58 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Dec 2011 13:59:58 -0500 Subject: [Pki-devel] [PATCH] 0022-TreeSet In-Reply-To: <1323282847.26127.1.camel@aleeredhat.laptop> References: <4EDD6EEB.4020406@redhat.com> <4EDED943.2070700@redhat.com> <4EDEDACE.3080601@redhat.com> <4EDEDB2C.7090402@redhat.com> <4EDF9862.9010202@redhat.com> <1323282847.26127.1.camel@aleeredhat.laptop> Message-ID: <4EDFB7AE.1080507@redhat.com> On 12/07/2011 01:34 PM, Ade Lee wrote: > The change we discussed on #dogtag-pki should be included. > > Specifically, > alee, this works > @SuppressWarnings("unchecked") > Vector newProfileList = (Vector) profileList.clone(); > mProfileList = newProfileList; > > Other than that, the patch looks good. > > Ade > On Wed, 2011-12-07 at 11:46 -0500, Adam Young wrote: >> On 12/06/2011 10:19 PM, Adam Young wrote: >>> On 12/06/2011 10:17 PM, Adam Young wrote: >>>> On 12/06/2011 10:10 PM, Adam Young wrote: >>>>> On 12/05/2011 08:24 PM, Adam Young wrote: >>>>>> More type safety cleanup. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pki-devel mailing list >>>>>> Pki-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>>> There was some concern that replacing the clone method with a >>>>> nother form of type safe copy would have performance >>>>> implications. This version replaces the clone. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pki-devel mailing list >>>>> Pki-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pki-devel >>>> Missed a couple changes in the last commit. >>>> >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> And missed an @SupressError in it as well. as left in a stray paren. >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> New version replaces some of the @Supress with catch blocks >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > pushed to master From alee at redhat.com Wed Dec 7 21:17:14 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 07 Dec 2011 16:17:14 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0002-Changes-to-the-formatting-of-comments.patch Message-ID: <1323292634.26127.6.camel@aleeredhat.laptop> Simple change to comments formatting. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0002-Changes-to-the-formatting-of-comments.patch Type: text/x-patch Size: 1807 bytes Desc: not available URL: From ayoung at redhat.com Wed Dec 7 21:21:10 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Dec 2011 16:21:10 -0500 Subject: [Pki-devel] [PATCH] pki-vakwetu-0002-Changes-to-the-formatting-of-comments.patch In-Reply-To: <1323292634.26127.6.camel@aleeredhat.laptop> References: <1323292634.26127.6.camel@aleeredhat.laptop> Message-ID: <4EDFD8C6.2020502@redhat.com> On 12/07/2011 04:17 PM, Ade Lee wrote: > Simple change to comments formatting. > Please review. > > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Dec 7 21:54:40 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 07 Dec 2011 16:54:40 -0500 Subject: [Pki-devel] Patch - pki-vakwetu-0003-Comment-formatting-change.patch Message-ID: <1323294886.26127.8.camel@aleeredhat.laptop> -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0003-Comment-formatting-change.patch Type: text/x-patch Size: 1514 bytes Desc: not available URL: From ayoung at redhat.com Wed Dec 7 21:55:16 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Dec 2011 16:55:16 -0500 Subject: [Pki-devel] Patch - pki-vakwetu-0003-Comment-formatting-change.patch In-Reply-To: <1323294886.26127.8.camel@aleeredhat.laptop> References: <1323294886.26127.8.camel@aleeredhat.laptop> Message-ID: <4EDFE0C4.6010906@redhat.com> On 12/07/2011 04:54 PM, Ade Lee wrote: > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Dec 7 22:04:25 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 07 Dec 2011 17:04:25 -0500 Subject: [Pki-devel] code reformat Message-ID: <1323295466.26127.11.camel@aleeredhat.laptop> Hi all, The code on the trunk has been reformatted to match the project code formatting specs. I did not post a patch because it was too large - but it basically was a lot of whitespace/tab and comment fixes mostly. In any case, you should probably rebase any outstanding patches on the new master (and be sure to fetch the latest). Ade From ayoung at redhat.com Thu Dec 8 02:13:37 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Dec 2011 21:13:37 -0500 Subject: [Pki-devel] [PATCH] 0023-Indent-in-conditionals Message-ID: <4EE01D51.5060105@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0023-Indent-in-conditionals.patch Type: text/x-patch Size: 9221 bytes Desc: not available URL: From ayoung at redhat.com Thu Dec 8 16:13:25 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 08 Dec 2011 11:13:25 -0500 Subject: [Pki-devel] [PATCH] 0023-Indent-in-conditionals In-Reply-To: <4EE01D51.5060105@redhat.com> References: <4EE01D51.5060105@redhat.com> Message-ID: <4EE0E225.6070900@redhat.com> On 12/07/2011 09:13 PM, Adam Young wrote: > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACKed by Ade Lee, pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Thu Dec 8 16:14:06 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 08 Dec 2011 11:14:06 -0500 Subject: [Pki-devel] [PATCH] 0023-Indent-in-conditionals In-Reply-To: <4EE01D51.5060105@redhat.com> References: <4EE01D51.5060105@redhat.com> Message-ID: <1323360846.12020.0.camel@aleeredhat.laptop> ACK On Wed, 2011-12-07 at 21:13 -0500, Adam Young wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Thu Dec 8 20:00:16 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 08 Dec 2011 15:00:16 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <4EDF8F58.5080708@redhat.com> References: <4EBC96B4.1010700@redhat.com> <1321454906.3201.7.camel@aleeredhat.laptop> <4EC3D8E6.6080002@redhat.com> <4EDF8F58.5080708@redhat.com> Message-ID: <4EE11750.2020103@redhat.com> On 12/07/2011 11:07 AM, Adam Young wrote: > On 11/16/2011 10:38 AM, Adam Young wrote: >> On 11/16/2011 09:48 AM, Ade Lee wrote: >>> I'm struggling with the premise behind this patch. Some of these >>> methods seem like they are valuable - and certainly they were valuable >>> at some point in time (or they would not have been written). On the >>> other hand, I see the benefit of trimming the code base. No need to >>> refactor code that isn't being used. >>> >>> I realize that this removes some eclipse warnings, but is removing >>> these >>> methods good practice? >>> >>> I guess I'm looking for some other folks to chime in here. >> >> My feeling is that you do not leave dead code in the code base. The >> code still exists in the repository, but it is unlikely that a piece >> of code that is not called today will be needed in exactly the same >> form in the future. >> >> >> Code is documentation. Code that is not used is misleading to the >> maintainer. Committing commented out code is a bad practice. >> >> As we refactor, the location of the behavior of a lot of these >> methods will change. Thus, some orphan calls will become >> uncallable, and others will get in the way of code clean up. >> >> >> This is old code: some of it goes back 15 years. Holding on to >> unused, uncallable code is akin to hoarding. >> >> >>> >>> Ade >>> >>> On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: >>>> _______________________________________________ >>>> 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 > > > Conflicted with the PKI Silent changes, so patch has been remade by > hand. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Withdrawn., The formatting changes make it impractical to try and reformat this. Will be resubmitted in smaller patches shortly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 9 02:25:52 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 08 Dec 2011 21:25:52 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <4EE11750.2020103@redhat.com> References: <4EBC96B4.1010700@redhat.com> <1321454906.3201.7.camel@aleeredhat.laptop> <4EC3D8E6.6080002@redhat.com> <4EDF8F58.5080708@redhat.com> <4EE11750.2020103@redhat.com> Message-ID: <4EE171B0.70801@redhat.com> On 12/08/2011 03:00 PM, Adam Young wrote: > On 12/07/2011 11:07 AM, Adam Young wrote: >> On 11/16/2011 10:38 AM, Adam Young wrote: >>> On 11/16/2011 09:48 AM, Ade Lee wrote: >>>> I'm struggling with the premise behind this patch. Some of these >>>> methods seem like they are valuable - and certainly they were valuable >>>> at some point in time (or they would not have been written). On the >>>> other hand, I see the benefit of trimming the code base. No need to >>>> refactor code that isn't being used. >>>> >>>> I realize that this removes some eclipse warnings, but is removing >>>> these >>>> methods good practice? >>>> >>>> I guess I'm looking for some other folks to chime in here. >>> >>> My feeling is that you do not leave dead code in the code base. The >>> code still exists in the repository, but it is unlikely that a >>> piece of code that is not called today will be needed in exactly the >>> same form in the future. >>> >>> >>> Code is documentation. Code that is not used is misleading to the >>> maintainer. Committing commented out code is a bad practice. >>> >>> As we refactor, the location of the behavior of a lot of these >>> methods will change. Thus, some orphan calls will become >>> uncallable, and others will get in the way of code clean up. >>> >>> >>> This is old code: some of it goes back 15 years. Holding on to >>> unused, uncallable code is akin to hoarding. >>> >>> >>>> >>>> Ade >>>> >>>> On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: >>>>> _______________________________________________ >>>>> 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 >> >> >> Conflicted with the PKI Silent changes, so patch has been remade by >> hand. >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Withdrawn., The formatting changes make it impractical to try and > reformat this. Will be resubmitted in smaller patches shortly. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Rebased on top of the format changes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0015-2-Removal-of-unused-private-methods.patch Type: text/x-patch Size: 129468 bytes Desc: not available URL: From alee at redhat.com Fri Dec 9 02:36:06 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 08 Dec 2011 21:36:06 -0500 Subject: [Pki-devel] Formatting code Message-ID: <1323398167.12020.18.camel@aleeredhat.laptop> Hi all, Based on seeing how Eclipse mangles line wrapping, we've decided to revert the formatting changes. We will reattempt this after Adam's set of generics patches have been applied. It may make sense to approach this as follows: 1. reformat without line wrapping. This will get all the basic things we want - getting rid of tabs, adjusting to sun coding standards etc. without worrying about the line wrapping. 2. Then reformat individual packages using line wrapping. This would give us smaller packages that we could examine to ensure that strange reformatting does not occur. We could also consider raising the line limit to 120 or 100, say, which would reduce the amount of line wrapping - and the number of troublesome cases. Any other suggestions would be welcome. In any case, you all probably want to rebase. Ade From rcritten at redhat.com Fri Dec 9 14:28:45 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 09:28:45 -0500 Subject: [Pki-devel] IPA dogtag clone failure Message-ID: <4EE21B1D.5020709@redhat.com> We have a report of a failed clone installation in the context of an IPA server. I haven't been able to figure out the cause, can someone take a look? The thread is at https://www.redhat.com/archives/freeipa-users/2011-December/msg00056.html thanks rob From alee at redhat.com Fri Dec 9 14:46:19 2011 From: alee at redhat.com (Ade Lee) Date: Fri, 09 Dec 2011 09:46:19 -0500 Subject: [Pki-devel] IPA dogtag clone failure In-Reply-To: <4EE21B1D.5020709@redhat.com> References: <4EE21B1D.5020709@redhat.com> Message-ID: <1323441979.12020.20.camel@aleeredhat.laptop> Rob, We need to know whats in the security domain. This will be printed out in the debug log. Ade On Fri, 2011-12-09 at 09:28 -0500, Rob Crittenden wrote: > We have a report of a failed clone installation in the context of an IPA > server. I haven't been able to figure out the cause, can someone take a > look? > > The thread is at > https://www.redhat.com/archives/freeipa-users/2011-December/msg00056.html > > thanks > > rob > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From rcritten at redhat.com Fri Dec 9 18:27:03 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 13:27:03 -0500 Subject: [Pki-devel] IPA dogtag clone failure In-Reply-To: <1323441979.12020.20.camel@aleeredhat.laptop> References: <4EE21B1D.5020709@redhat.com> <1323441979.12020.20.camel@aleeredhat.laptop> Message-ID: <4EE252F7.60401@redhat.com> Ade Lee wrote: > Rob, > > We need to know whats in the security domain. This will be printed out > in the debug log. Attached rob > > Ade > > On Fri, 2011-12-09 at 09:28 -0500, Rob Crittenden wrote: >> We have a report of a failed clone installation in the context of an IPA >> server. I haven't been able to figure out the cause, can someone take a >> look? >> >> The thread is at >> https://www.redhat.com/archives/freeipa-users/2011-December/msg00056.html >> >> thanks >> >> rob >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: debug.dscott URL: From release-engineering at redhat.com Mon Dec 12 03:11:39 2011 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Sun, 11 Dec 2011 22:11:39 -0500 Subject: [Pki-devel] [engineering.redhat.com #130939] Request to enable nightly builds of 'ipa-pki-theme' and 'pki-core' on Fedora 16 and Fedora 17 (rawhide) In-Reply-To: <4ED688B9.2090702@redhat.com> References: <4ED688B9.2090702@redhat.com> Message-ID: Ticket nightly builds are now running for fedora 16 on machine lemony1.dsdev.sjc.redhat.com. working on setting up fedora 17 on lemony2.dsdev.sjc.redhat.com From release-engineering at redhat.com Tue Dec 13 04:47:36 2011 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Mon, 12 Dec 2011 23:47:36 -0500 Subject: [Pki-devel] [engineering.redhat.com #130939] Request to enable nightly builds of 'ipa-pki-theme' and 'pki-core' on Fedora 16 and Fedora 17 (rawhide) In-Reply-To: <4ED688B9.2090702@redhat.com> References: <4ED688B9.2090702@redhat.com> Message-ID: Ticket nightly builds now running on both fedora 16 (lemony1.dsdev.sjc.redhat.com) and rawhide (lemony2.dsdev.sjc.redhat.com) closing. From edewata at redhat.com Tue Dec 13 17:47:00 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 13 Dec 2011 11:47:00 -0600 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. Message-ID: <4EE78F94.6080705@redhat.com> The byte-to-char and char-to-byte converters have been replaced with a set of charsets, each having its own decoders and encoders. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0004-Replaced-byte-to-char-char-to-byte-converters.patch Type: text/x-patch Size: 89160 bytes Desc: not available URL: From ayoung at redhat.com Tue Dec 13 18:18:27 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 13 Dec 2011 13:18:27 -0500 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EE78F94.6080705@redhat.com> References: <4EE78F94.6080705@redhat.com> Message-ID: <4EE796F3.7030204@redhat.com> On 12/13/2011 12:47 PM, Endi Sukma Dewata wrote: > The byte-to-char and char-to-byte converters have been replaced > with a set of charsets, each having its own decoders and encoders. > > Ticket #3 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Nicely done, I've given it a visual quick look over. A minor nit is that you shouldn't use import java.util.*; but instead list the elements individually. I would like to see this split into two patches, one that moves the files into the proper package and a second that changes to the nondeprecated API. If you have it that way in your Git repo, please post it, so I can see what is changed in the moved files. If not, it isn't that hard to set up to do the diff by hand. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Dec 13 18:49:04 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 13 Dec 2011 12:49:04 -0600 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EE796F3.7030204@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE796F3.7030204@redhat.com> Message-ID: <4EE79E20.5060700@redhat.com> On 12/13/2011 12:18 PM, Adam Young wrote: > On 12/13/2011 12:47 PM, Endi Sukma Dewata wrote: >> The byte-to-char and char-to-byte converters have been replaced >> with a set of charsets, each having its own decoders and encoders. >> >> Ticket #3 > > Nicely done, I've given it a visual quick look over. A minor nit is that > you shouldn't use > > import java.util.*; but instead list the elements individually. OK, that can be changed. > I would like to see this split into two patches, one that moves the > files into the proper package and a second that changes to the > nondeprecated API. If you have it that way in your Git repo, please post > it, so I can see what is changed in the moved files. If not, it isn't > that hard to set up to do the diff by hand. The package isn't changed, I'm only renaming the files according to the class hierarchy. It probably wouldn't make sense to have an IA5CharsetDecoder inheriting from ByteToCharConverter, but I can redo the patch to do that if you want, it's not difficult. -- Endi S. Dewata From awnuk at redhat.com Tue Dec 13 19:03:00 2011 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 13 Dec 2011 11:03:00 -0800 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EE78F94.6080705@redhat.com> References: <4EE78F94.6080705@redhat.com> Message-ID: <4EE7A164.5030709@redhat.com> On 12/13/2011 09:47 AM, Endi Sukma Dewata wrote: > The byte-to-char and char-to-byte converters have been replaced > with a set of charsets, each having its own decoders and encoders. > > Ticket #3 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Hopefully this patch was extremely well tested since it touches ASN.1 encoding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Dec 13 21:55:53 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 13 Dec 2011 16:55:53 -0500 Subject: [Pki-devel] skeleton code for drm restful interface Message-ID: <1323813353.9247.28.camel@aleeredhat.laptop> Attached is some skeleton code for the new DRM interface. To build, you will need to download and install the candlepin-deps rpm. (http://repos.fedorapeople.org/repos/candlepin/candlepin/) We will use these rpms to build/run until we get the resteasy packages into Fedora. The new classes provide the following: 1. interface to list/get/submit key requests (for archival and recovery). 2. interface to recover keys 3. interface to approve/reject key recovery requests. 4. input/output via XML/JSON/browser. This is pretty much just a skeleton as not all the functionality is currently in the DRM. There is also no authentication/authz as Jack has yet to work that part out. But it does look pretty much like what the restful interface will probably look like - and the comments point out the parts that are missing. Jack - please look to see how your new code would interact with this - and also in terms of the input/output parameters/structures. Endi, Adam: please look to see if the structure/ coding makes sense - or if it can be improved. Its not at all final - but all feedback will help. To test, you can do the following: 1. Build the code. You will need to replace pki-common and pki-kra. 2. pkicreate and configure a DRM. The needed changes to web.xml should be in the new instance. 3. Add links to the following jars in webapps/lib/. They should all be in /usr/share/candlepin/lib --> javassist, jaxrs-api, jettison, resteasy-jaxb-provider, resteasy-jaxrs, resteasy-jettison-provider, scannotation 4. Archive some keys by doing enrollments with your CA or TPS. You could also set up the DRM instance to be controlled by eclipse in the same way that we do for the CA instance. If you do this, you will be able to step through the code with the debugger. You should be able to see archived enrollments/ recoveries by going to : https://hostname:port/kra/pki/keyrequests https://hostname:port/kra/pki/keyrequest/1 using a browser, or using curl to get xml or json. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0004-Initial-skeleton-code-for-drm-resteasy-interface.patch Type: text/x-patch Size: 48709 bytes Desc: not available URL: From ayoung at redhat.com Tue Dec 13 22:25:29 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 13 Dec 2011 17:25:29 -0500 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EE7A164.5030709@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> Message-ID: <4EE7D0D9.1090400@redhat.com> On 12/13/2011 02:03 PM, Andrew Wnuk wrote: > On 12/13/2011 09:47 AM, Endi Sukma Dewata wrote: >> The byte-to-char and char-to-byte converters have been replaced >> with a set of charsets, each having its own decoders and encoders. >> >> Ticket #3 >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > Hopefully this patch was extremely well tested since it touches ASN.1 > encoding. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Do you have a specific set of tests that we should be running? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Tue Dec 13 23:07:50 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 13 Dec 2011 18:07:50 -0500 Subject: [Pki-devel] skeleton code for drm restful interface In-Reply-To: <1323813353.9247.28.camel@aleeredhat.laptop> References: <1323813353.9247.28.camel@aleeredhat.laptop> Message-ID: <4EE7DAC6.2080908@redhat.com> On 12/13/2011 04:55 PM, Ade Lee wrote: > Attached is some skeleton code for the new DRM interface. To build, you > will need to download and install the candlepin-deps rpm. > (http://repos.fedorapeople.org/repos/candlepin/candlepin/) > > We will use these rpms to build/run until we get the resteasy packages > into Fedora. > > The new classes provide the following: > 1. interface to list/get/submit key requests (for archival and > recovery). > 2. interface to recover keys > 3. interface to approve/reject key recovery requests. > 4. input/output via XML/JSON/browser. > > This is pretty much just a skeleton as not all the functionality is > currently in the DRM. There is also no authentication/authz as Jack has > yet to work that part out. But it does look pretty much like what the > restful interface will probably look like - and the comments point out > the parts that are missing. > > Jack - please look to see how your new code would interact with this - > and also in terms of the input/output parameters/structures. > > Endi, Adam: please look to see if the structure/ coding makes sense - or > if it can be improved. Its not at all final - but all feedback will > help. I'd forgotten how annoying I find the Bean API. You catch too many exceptions. Let them propagate as far as you can. You should not be cathing them and then rethrowing them. Either catch them and be done with them, or let them bubble up to the top level. I understand the reason for splitting the DAO off from the servlet, but I feel that here the division is too arbitrary. The Resource doesn't do any work, and the fact that these are all methods of the same objects although they do the same thing seems arbitrary. I realize you are following the examples given in the documentation. I think that the Repository already playts the role of the DAO, and putting an additionaly layer in here provides no additional insulation against leaky abstractions.... I also really don't like the split between KeyData and KeyDataInfo. It seems unnecessary. Let the complexity emerge. Write the code in a more inline fashion, and only refactor out once you have a sense of what the real structure is going to be. I'll try to send you back my version of the patch tomorrow: I'm about to lose Laptop battery right now. > > To test, you can do the following: > 1. Build the code. You will need to replace pki-common and pki-kra. > 2. pkicreate and configure a DRM. The needed changes to web.xml should > be in the new instance. > 3. Add links to the following jars in webapps/lib/. They should all be > in /usr/share/candlepin/lib > --> javassist, jaxrs-api, jettison, resteasy-jaxb-provider, > resteasy-jaxrs, resteasy-jettison-provider, scannotation > 4. Archive some keys by doing enrollments with your CA or TPS. > > You could also set up the DRM instance to be controlled by eclipse in > the same way that we do for the CA instance. If you do this, you will > be able to step through the code with the debugger. > > You should be able to see archived enrollments/ recoveries by going to : > https://hostname:port/kra/pki/keyrequests > https://hostname:port/kra/pki/keyrequest/1 > > using a browser, or using curl to get xml or json. > > Ade > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Dec 14 03:21:45 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 13 Dec 2011 22:21:45 -0500 Subject: [Pki-devel] skeleton code for drm restful interface In-Reply-To: <4EE7DAC6.2080908@redhat.com> References: <1323813353.9247.28.camel@aleeredhat.laptop> <4EE7DAC6.2080908@redhat.com> Message-ID: <1323832906.9247.65.camel@aleeredhat.laptop> On Tue, 2011-12-13 at 18:07 -0500, Adam Young wrote: > On 12/13/2011 04:55 PM, Ade Lee wrote: > > Attached is some skeleton code for the new DRM interface. To build, you > > will need to download and install the candlepin-deps rpm. > > (http://repos.fedorapeople.org/repos/candlepin/candlepin/) > > > > We will use these rpms to build/run until we get the resteasy packages > > into Fedora. > > > > The new classes provide the following: > > 1. interface to list/get/submit key requests (for archival and > > recovery). > > 2. interface to recover keys > > 3. interface to approve/reject key recovery requests. > > 4. input/output via XML/JSON/browser. > > > > This is pretty much just a skeleton as not all the functionality is > > currently in the DRM. There is also no authentication/authz as Jack has > > yet to work that part out. But it does look pretty much like what the > > restful interface will probably look like - and the comments point out > > the parts that are missing. > > > > Jack - please look to see how your new code would interact with this - > > and also in terms of the input/output parameters/structures. > > > > Endi, Adam: please look to see if the structure/ coding makes sense - or > > if it can be improved. Its not at all final - but all feedback will > > help. > > I'd forgotten how annoying I find the Bean API. > > You catch too many exceptions. Let them propagate as far as you can. > You should not be cathing them and then rethrowing them. Either catch > them and be done with them, or let them bubble up to the top level. > Thats fair. I planned to handle them at the top level - so I can just let them bubble up. > I understand the reason for splitting the DAO off from the servlet, > but I feel that here the division is too arbitrary. The Resource > doesn't do any work, and the fact that these are all methods of the > same objects although they do the same thing seems arbitrary. I > realize you are following the examples given in the documentation. I > think that the Repository already playts the role of the DAO, and > putting an additionaly layer in here provides no additional insulation > against leaky abstractions.... > When I originally started this, I had a bunch of private methods in the resource servlet that did the work that is now encapsulated in the DAO classes. I also had the idea that the RequestQueue and Repository were essentally DAO objects. But then, I thought that I might want to code the ability to code a function that would allow one to submit a recovery request that is automatically processed and return the relevant key data. That would then mean having logic to access both the request queue and the key repository in the same servlet. In fact, more likely than not, I would need to duplicate code to extract a key (using the repository) in both the KeyRequest and Key resources. The alternative is for both resources to use a KeyDAO object and call a common recoverKey() method. At that point, I started thinking about introducing DAO objects - and I think the code is actually better for it. The distinction in the code is not arbitrary. The Resource classes show exactly which interfaces are being exposed - and how they are being exposed ie. the XML structure needed to communicate. They also ultimately detail how error conditions and exceptions are communicated to the client. My idea was that all exceptions ultimately need to be handled at this level. I did this by propagating them up - but I can just let them pass through too. And they include code needed to validate the request -- more of which is likely to be needed -- prior to sending the request to a DAO object to extract data. The reason that they appear not to do any work is because the details on how the engine interacts with the repo -- have been abstracted away. Also, there are things that are missing still -- logging, audit logging, more request validation, details on how to parse the search parameters etc. All in all, the resource classes are going to do a lot more, and keeping them focused on the "external" interactions is not a bad thing. > > I also really don't like the split between KeyData and KeyDataInfo. > It seems unnecessary. > They are two very different things. KeyDataInfo is something that you would get back if you wanted to list the keys stored. For example, I might want to list all the keys stored for a particular client ID. This would provide identifiers for the keys and some basic data. We will likely need to add more fields as we flesh it all out. KeyData is the actual key (appropriately wrapped). It is what comes back when a key recovery request is processed. Are you suggesting that they be combined - and that some fields would just be empty depending on the request? That actually may not be a bad idea ... > > Let the complexity emerge. Write the code in a more inline fashion, > and only refactor out once you have a sense of what the real structure > is going to be. I'll try to send you back my version of the patch > tomorrow: I'm about to lose Laptop battery right now. > Adam - I did do that - and then started refactoring when I started thinking about - for example - writing a call to automatically process recovery requests. That said - this is a first draft. So keep the suggestions coming. > > > > > To test, you can do the following: > > 1. Build the code. You will need to replace pki-common and pki-kra. > > 2. pkicreate and configure a DRM. The needed changes to web.xml should > > be in the new instance. > > 3. Add links to the following jars in webapps/lib/. They should all be > > in /usr/share/candlepin/lib > > --> javassist, jaxrs-api, jettison, resteasy-jaxb-provider, > > resteasy-jaxrs, resteasy-jettison-provider, scannotation > > 4. Archive some keys by doing enrollments with your CA or TPS. > > > > You could also set up the DRM instance to be controlled by eclipse in > > the same way that we do for the CA instance. If you do this, you will > > be able to step through the code with the debugger. > > > > You should be able to see archived enrollments/ recoveries by going to : > > https://hostname:port/kra/pki/keyrequests > > https://hostname:port/kra/pki/keyrequest/1 > > > > using a browser, or using curl to get xml or json. > > > > 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 ayoung at redhat.com Wed Dec 14 15:54:35 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 14 Dec 2011 10:54:35 -0500 Subject: [Pki-devel] [PATCH] 0025-Simple-Name In-Reply-To: <1323808115.9247.1.camel@aleeredhat.laptop> References: <1323808115.9247.1.camel@aleeredhat.laptop> Message-ID: <4EE8C6BB.4050206@redhat.com> This is not ready for commit, but I want people to start getting eyes on it. I know it builds but have not checked beyond that part. I am reworking a large number of changes into a set of manageble sized patches and I think I have all of the dependencies for these changes in this patch, but I have not yet confirmed that. -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0025-2-Simple-Name.patch Type: text/x-patch Size: 500634 bytes Desc: not available URL: From ayoung at redhat.com Wed Dec 14 16:48:43 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 14 Dec 2011 11:48:43 -0500 Subject: [Pki-devel] skeleton code for drm restful interface In-Reply-To: <1323832906.9247.65.camel@aleeredhat.laptop> References: <1323813353.9247.28.camel@aleeredhat.laptop> <4EE7DAC6.2080908@redhat.com> <1323832906.9247.65.camel@aleeredhat.laptop> Message-ID: <4EE8D36B.9050106@redhat.com> On 12/13/2011 10:21 PM, Ade Lee wrote: > On Tue, 2011-12-13 at 18:07 -0500, Adam Young wrote: >> On 12/13/2011 04:55 PM, Ade Lee wrote: >>> Attached is some skeleton code for the new DRM interface. To build, you >>> will need to download and install the candlepin-deps rpm. >>> (http://repos.fedorapeople.org/repos/candlepin/candlepin/) >>> >>> We will use these rpms to build/run until we get the resteasy packages >>> into Fedora. >>> >>> The new classes provide the following: >>> 1. interface to list/get/submit key requests (for archival and >>> recovery). >>> 2. interface to recover keys >>> 3. interface to approve/reject key recovery requests. >>> 4. input/output via XML/JSON/browser. >>> >>> This is pretty much just a skeleton as not all the functionality is >>> currently in the DRM. There is also no authentication/authz as Jack has >>> yet to work that part out. But it does look pretty much like what the >>> restful interface will probably look like - and the comments point out >>> the parts that are missing. >>> >>> Jack - please look to see how your new code would interact with this - >>> and also in terms of the input/output parameters/structures. >>> >>> Endi, Adam: please look to see if the structure/ coding makes sense - or >>> if it can be improved. Its not at all final - but all feedback will >>> help. >> I'd forgotten how annoying I find the Bean API. >> >> You catch too many exceptions. Let them propagate as far as you can. >> You should not be cathing them and then rethrowing them. Either catch >> them and be done with them, or let them bubble up to the top level. >> > Thats fair. I planned to handle them at the top level - so I can just > let them bubble up. > >> I understand the reason for splitting the DAO off from the servlet, >> but I feel that here the division is too arbitrary. The Resource >> doesn't do any work, and the fact that these are all methods of the >> same objects although they do the same thing seems arbitrary. I >> realize you are following the examples given in the documentation. I >> think that the Repository already playts the role of the DAO, and >> putting an additionaly layer in here provides no additional insulation >> against leaky abstractions.... >> > When I originally started this, I had a bunch of private methods in the > resource servlet that did the work that is now encapsulated in the DAO > classes. I also had the idea that the RequestQueue and Repository were > essentally DAO objects. > > But then, I thought that I might want to code the ability to code a > function that would allow one to submit a recovery request that is > automatically processed and return the relevant key data. That would > then mean having logic to access both the request queue and the key > repository in the same servlet. In fact, more likely than not, I would > need to duplicate code to extract a key (using the repository) in both > the KeyRequest and Key resources. The alternative is for both resources > to use a KeyDAO object and call a common recoverKey() method. > > At that point, I started thinking about introducing DAO objects - and I > think the code is actually better for it. > > The distinction in the code is not arbitrary. The Resource classes show > exactly which interfaces are being exposed - and how they are being > exposed ie. the XML structure needed to communicate. They also > ultimately detail how error conditions and exceptions are communicated > to the client. My idea was that all exceptions ultimately need to be > handled at this level. I did this by propagating them up - but I can > just let them pass through too. > > And they include code needed to validate the request -- more of which is > likely to be needed -- prior to sending the request to a DAO object to > extract data. > > The reason that they appear not to do any work is because the details on > how the engine interacts with the repo -- have been abstracted away. > Also, there are things that are missing still -- logging, audit logging, > more request validation, details on how to parse the search parameters > etc. > > All in all, the resource classes are going to do a lot more, and keeping > them focused on the "external" interactions is not a bad thing. All good ideas. If we think 3 tiers, the resource is the interface tier, the DAO is the Business logic, and the Key and KeyData classes are the data. But we don't need one DAO per data type, and I think a lot of this code can be simplified to start. But IKeyRecovery in this case is the DAO. With the Data layer being KeyRecord. Of course, the code in those classes need serious cleanup. The MultiMap object should be constrained to the Interface leyer, and should be converted to a POJO up front. Ideally, an immutable one. Extract the following code into a builder. public RecoveryRequestData(MultivaluedMap form) { keyId = form.getFirst(KEY_ID); requestId = form.getFirst(REQUEST_ID); transWrappedSessionKey = form.getFirst(TRANS_WRAPPED_SESSION_KEY); transWrappedPassphrase = form.getFirst(TRANS_WRAPPED_PASSPHRASE); } And then have the RecoveryRequestData take in the specific values it needs in its constructor. Note that they should not be strings, but instead more specific data types. It is OK for these objects to have a String constructor. So something like RecoveryRequestData(KeyId keyId, Request request, Key wrappedSessionKey, Passphrase wrappedPassphrase){...} You get the idea. If it has a string constructor and a correct toString function, it should be convertable. It may mean that we need to do something to tag them for marshalling. I fear that again the XML marshalling will force no-arg constructors. > >> I also really don't like the split between KeyData and KeyDataInfo. >> It seems unnecessary. >> > They are two very different things. > > KeyDataInfo is something that you would get back if you wanted to list > the keys stored. For example, I might want to list all the keys stored > for a particular client ID. This would provide identifiers for the keys > and some basic data. We will likely need to add more fields as we flesh > it all out. > > KeyData is the actual key (appropriately wrapped). It is what comes > back when a key recovery request is processed. > > Are you suggesting that they be combined - and that some fields would > just be empty depending on the request? That actually may not be a bad > idea ... We should probably reflect the structure in the DirSrv. But I can see the argument for wanting to manage the Info and the key itself separately. > >> Let the complexity emerge. Write the code in a more inline fashion, >> and only refactor out once you have a sense of what the real structure >> is going to be. I'll try to send you back my version of the patch >> tomorrow: I'm about to lose Laptop battery right now. >> > Adam - I did do that - and then started refactoring when I started > thinking about - for example - writing a call to automatically process > recovery requests. > > That said - this is a first draft. So keep the suggestions coming. Looks good, and I can see where you are coming from. I think that to start with, refactor to Static methods first, and don't hold on to state that you don't need. For example, you can make a helper function like this: public static IKeyRepository getKeyRepository() { return ((IKeyRecoveryAuthority) CMS.getSubsystem("kra")) .getKeyRepository(); } and then something like Enumeration e = KeyResource.getKeyRepository().searchKeys(filter, KeysResource.maxSize, KeysResource.maxTime); There is no need to hold on to references like this across method calls. I'm in meetings all day today and tomorrow, but should have more time to address this on Friday. >>> To test, you can do the following: >>> 1. Build the code. You will need to replace pki-common and pki-kra. >>> 2. pkicreate and configure a DRM. The needed changes to web.xml should >>> be in the new instance. >>> 3. Add links to the following jars in webapps/lib/. They should all be >>> in /usr/share/candlepin/lib >>> --> javassist, jaxrs-api, jettison, resteasy-jaxb-provider, >>> resteasy-jaxrs, resteasy-jettison-provider, scannotation >>> 4. Archive some keys by doing enrollments with your CA or TPS. >>> >>> You could also set up the DRM instance to be controlled by eclipse in >>> the same way that we do for the CA instance. If you do this, you will >>> be able to step through the code with the debugger. >>> >>> You should be able to see archived enrollments/ recoveries by going to : >>> https://hostname:port/kra/pki/keyrequests >>> https://hostname:port/kra/pki/keyrequest/1 >>> >>> using a browser, or using curl to get xml or json. >>> >>> 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 Joshua.Roys at gtri.gatech.edu Fri Dec 16 19:35:41 2011 From: Joshua.Roys at gtri.gatech.edu (Joshua Roys) Date: Fri, 16 Dec 2011 14:35:41 -0500 Subject: [Pki-devel] [PATCH] Add support for RFC4043 permanent identifiers Message-ID: <4EEB9D8D.6080204@gtri.gatech.edu> Hello, Attached is a patch to implement (half of) RFC4043 Permanent Identifiers. The cases where the identifierValue is not supplied are not supported. (This was tested on pki 1.3.x and sometime soon I will test it on 9.0.x also.) I'm not sure if the code reformatting is done yet, so I'll rebase this patch later if need be. Also, either a V2 of this patch or a follow-up will add pretty-printing. Josh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-support-for-RFC4043-permanent-identifiers.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5045 bytes Desc: S/MIME Cryptographic Signature URL: From edewata at redhat.com Sat Dec 17 01:22:59 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 16 Dec 2011 19:22:59 -0600 Subject: [Pki-devel] [PATCH] 5 Added unit tests for pki-util. Message-ID: <4EEBEEF3.3050909@redhat.com> New unit tests have been added to test string converters indirectly. This is to allow replacing the converters with charset encoder and decoder without changing the test cases. The TestRunner has been moved into a separate package such that it can be reused by other packages. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0005-Added-unit-tests-for-pki-util.patch Type: text/x-patch Size: 70261 bytes Desc: not available URL: From edewata at redhat.com Sat Dec 17 01:24:29 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 16 Dec 2011 19:24:29 -0600 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EE7D0D9.1090400@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> Message-ID: <4EEBEF4D.5060402@redhat.com> On 12/13/2011 4:25 PM, Adam Young wrote: > On 12/13/2011 02:03 PM, Andrew Wnuk wrote: >> Hopefully this patch was extremely well tested since it touches ASN.1 >> encoding. > Do you have a specific set of tests that we should be running? I just posted patch #5 which contains some unit tests for the converters. I've also updated and split patch #4 into #4-2a (renaming the files) and #4-2b (replacing the implementation). Patch #5 should be applied before #4-2a/b to make sure there's no regression. Mozilla JSS library also has some ASN.1 code, should we use them to implement the converters? http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/asn1/ -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0004-2a-Renamed-byte-to-char-char-to-byte-converters.patch Type: text/x-patch Size: 13897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0004-2b-Replaced-byte-to-char-char-to-byte-converters.patch Type: text/x-patch Size: 70266 bytes Desc: not available URL: From ayoung at redhat.com Mon Dec 19 15:53:58 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 19 Dec 2011 10:53:58 -0500 Subject: [Pki-devel] [PATCH] 5 Added unit tests for pki-util. In-Reply-To: <4EEBEEF3.3050909@redhat.com> References: <4EEBEEF3.3050909@redhat.com> Message-ID: <4EEF5E16.6070606@redhat.com> On 12/16/2011 08:22 PM, Endi Sukma Dewata wrote: > New unit tests have been added to test string converters indirectly. > This is to allow replacing the converters with charset encoder and > decoder without changing the test cases. > > The TestRunner has been moved into a separate package such that it > can be reused by other packages. > > Ticket #3 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Dec 19 16:11:25 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 19 Dec 2011 11:11:25 -0500 Subject: [Pki-devel] Merging dogtag and ipa databases Message-ID: <1324311086.12374.5.camel@aleeredhat.laptop> Hi all, Based on conversations with Adam, Simo and Rob, here are some thoughts on $subject: http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases I'll probably add more later - like the details on how cloned instance installation will run. Comments are welcome. Ade From ayoung at redhat.com Tue Dec 20 19:55:08 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 20 Dec 2011 14:55:08 -0500 Subject: [Pki-devel] [PATCH] 0026 encode utf8 Message-ID: <4EF0E81C.7000200@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0026-encode-utf-8.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: From alee at redhat.com Tue Dec 20 20:21:10 2011 From: alee at redhat.com (Ade Lee) Date: Tue, 20 Dec 2011 15:21:10 -0500 Subject: [Pki-devel] [PATCH] 0026 encode utf8 In-Reply-To: <4EF0E81C.7000200@redhat.com> References: <4EF0E81C.7000200@redhat.com> Message-ID: <1324412471.4868.2.camel@aleeredhat.laptop> ack On Tue, 2011-12-20 at 14:55 -0500, Adam Young wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From ayoung at redhat.com Tue Dec 20 20:23:49 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 20 Dec 2011 15:23:49 -0500 Subject: [Pki-devel] [PATCH] 0026 encode utf8 In-Reply-To: <1324412471.4868.2.camel@aleeredhat.laptop> References: <4EF0E81C.7000200@redhat.com> <1324412471.4868.2.camel@aleeredhat.laptop> Message-ID: <4EF0EED5.6070105@redhat.com> On 12/20/2011 03:21 PM, Ade Lee wrote: > ack > On Tue, 2011-12-20 at 14:55 -0500, Adam Young wrote: >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > pushed to master From mharmsen at redhat.com Tue Dec 20 22:36:27 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 20 Dec 2011 14:36:27 -0800 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <4EE171B0.70801@redhat.com> References: <4EBC96B4.1010700@redhat.com> <1321454906.3201.7.camel@aleeredhat.laptop> <4EC3D8E6.6080002@redhat.com> <4EDF8F58.5080708@redhat.com> <4EE11750.2020103@redhat.com> <4EE171B0.70801@redhat.com> Message-ID: <4EF10DEB.4050101@redhat.com> On 12/08/11 18:25, Adam Young wrote: > On 12/08/2011 03:00 PM, Adam Young wrote: >> On 12/07/2011 11:07 AM, Adam Young wrote: >>> On 11/16/2011 10:38 AM, Adam Young wrote: >>>> On 11/16/2011 09:48 AM, Ade Lee wrote: >>>>> I'm struggling with the premise behind this patch. Some of these >>>>> methods seem like they are valuable - and certainly they were >>>>> valuable >>>>> at some point in time (or they would not have been written). On the >>>>> other hand, I see the benefit of trimming the code base. No need to >>>>> refactor code that isn't being used. >>>>> >>>>> I realize that this removes some eclipse warnings, but is removing >>>>> these >>>>> methods good practice? >>>>> >>>>> I guess I'm looking for some other folks to chime in here. >>>> >>>> My feeling is that you do not leave dead code in the code base. >>>> The code still exists in the repository, but it is unlikely that a >>>> piece of code that is not called today will be needed in exactly >>>> the same form in the future. >>>> >>>> >>>> Code is documentation. Code that is not used is misleading to the >>>> maintainer. Committing commented out code is a bad practice. >>>> >>>> As we refactor, the location of the behavior of a lot of these >>>> methods will change. Thus, some orphan calls will become >>>> uncallable, and others will get in the way of code clean up. >>>> >>>> >>>> This is old code: some of it goes back 15 years. Holding on to >>>> unused, uncallable code is akin to hoarding. >>>> >>>> >>>>> >>>>> Ade >>>>> >>>>> On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> Conflicted with the PKI Silent changes, so patch has been remade by >>> hand. >>> >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> Withdrawn., The formatting changes make it impractical to try and >> reformat this. Will be resubmitted in smaller patches shortly. >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Rebased on top of the format changes > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK - although the "reformatting" may need to be changed since this patch was based upon having the formatting patch applied which has since been reverted. After performing the following commands, I also was able to successfully apply this patch using the following commands: * git reset --hard HEAD~1 (from "master" --- was used to remove a previously broken patch) * git branch unused_private_methods * git checkout unused_private_methods * git am --whitespace=fix --signoff < dogtag-admiyo-0015-2-Removal-of-unused-private-methods.patch I was able to successfully build this branch from both Eclipse and using the "pki/scripts/compose_pki_core_packages" script. I installed the packages that I built, ran "pkicreate", configured the CA via the Firefox browser, and successfully enrolled a certificate. -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Dec 21 01:40:32 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 20 Dec 2011 20:40:32 -0500 Subject: [Pki-devel] [PATCH] 0015-Removal-of-unused-private-methods In-Reply-To: <4EF10DEB.4050101@redhat.com> References: <4EBC96B4.1010700@redhat.com> <1321454906.3201.7.camel@aleeredhat.laptop> <4EC3D8E6.6080002@redhat.com> <4EDF8F58.5080708@redhat.com> <4EE11750.2020103@redhat.com> <4EE171B0.70801@redhat.com> <4EF10DEB.4050101@redhat.com> Message-ID: <4EF13910.9060100@redhat.com> On 12/20/2011 05:36 PM, Matthew Harmsen wrote: > On 12/08/11 18:25, Adam Young wrote: >> On 12/08/2011 03:00 PM, Adam Young wrote: >>> On 12/07/2011 11:07 AM, Adam Young wrote: >>>> On 11/16/2011 10:38 AM, Adam Young wrote: >>>>> On 11/16/2011 09:48 AM, Ade Lee wrote: >>>>>> I'm struggling with the premise behind this patch. Some of these >>>>>> methods seem like they are valuable - and certainly they were >>>>>> valuable >>>>>> at some point in time (or they would not have been written). On the >>>>>> other hand, I see the benefit of trimming the code base. No need to >>>>>> refactor code that isn't being used. >>>>>> >>>>>> I realize that this removes some eclipse warnings, but is >>>>>> removing these >>>>>> methods good practice? >>>>>> >>>>>> I guess I'm looking for some other folks to chime in here. >>>>> >>>>> My feeling is that you do not leave dead code in the code base. >>>>> The code still exists in the repository, but it is unlikely that >>>>> a piece of code that is not called today will be needed in exactly >>>>> the same form in the future. >>>>> >>>>> >>>>> Code is documentation. Code that is not used is misleading to the >>>>> maintainer. Committing commented out code is a bad practice. >>>>> >>>>> As we refactor, the location of the behavior of a lot of these >>>>> methods will change. Thus, some orphan calls will become >>>>> uncallable, and others will get in the way of code clean up. >>>>> >>>>> >>>>> This is old code: some of it goes back 15 years. Holding on to >>>>> unused, uncallable code is akin to hoarding. >>>>> >>>>> >>>>>> >>>>>> Ade >>>>>> >>>>>> On Thu, 2011-11-10 at 22:29 -0500, Adam Young wrote: >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> Conflicted with the PKI Silent changes, so patch has been remade >>>> by hand. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> Withdrawn., The formatting changes make it impractical to try and >>> reformat this. Will be resubmitted in smaller patches shortly. >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> Rebased on top of the format changes >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > ACK - although the "reformatting" may need to be changed since this > patch was based upon having the formatting patch applied which has > since been reverted. > > After performing the following commands, I also was able to > successfully apply this patch using the following commands: > > * git reset --hard HEAD~1 (from "master" --- was used to remove a > previously broken patch) > * git branch unused_private_methods > * git checkout unused_private_methods > * git am --whitespace=fix --signoff < > dogtag-admiyo-0015-2-Removal-of-unused-private-methods.patch > > I was able to successfully build this branch from both Eclipse and > using the "pki/scripts/compose_pki_core_packages" script. > > I installed the packages that I built, ran "pkicreate", configured the > CA via the Firefox browser, and successfully enrolled a certificate. > > -- Matt > Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Wed Dec 21 02:19:05 2011 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 20 Dec 2011 18:19:05 -0800 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EEBEF4D.5060402@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> Message-ID: <4EF14219.7030902@redhat.com> On 12/16/11 17:24, Endi Sukma Dewata wrote: > On 12/13/2011 4:25 PM, Adam Young wrote: >> On 12/13/2011 02:03 PM, Andrew Wnuk wrote: >>> Hopefully this patch was extremely well tested since it touches ASN.1 >>> encoding. >> Do you have a specific set of tests that we should be running? > > I just posted patch #5 which contains some unit tests for the > converters. I've also updated and split patch #4 into #4-2a (renaming > the files) and #4-2b (replacing the implementation). > > Patch #5 should be applied before #4-2a/b to make sure there's no > regression. > > Mozilla JSS library also has some ASN.1 code, should we use them to > implement the converters? > > http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/asn1/ > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Endi, Andrew and I have been looking at these changes, and we have the following concerns: (1) First of all, we looked up the bug where some of the sun.io.* classes were deprecated (which mentions java.nio.charset and sun.nio.cs): * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948149 (2) There appears to be considerable concern on performance degradation when using "Charset": * http://stackoverflow.com/questions/2098137/fast-alternative-to-java-nio-charset-charset-decode-encode * http://www.theserverside.com/discussions/thread.tss?thread_id=61270 (3) Additionally, there have been alterations in the CS code in the past to fix problems encountered with the sun.io.* classes: * pki/base/util/src/netscape/security/util/ByteToCharPrintable.java Although we have not gotten to the unit tests, we suspect that these will be great to have regardless of the direction that is decided upon. However, due to our concerns regarding performance, could we have some tests added (unit or a test tool) which obtain performance results for the existing methods versus the proposed newer methods? If no discernable performance issues are encountered, most of these changes appear to be acceptable -- the questionable one being the replacing of the code that addressed issue (3) above. If there is an unacceptable degradation in performance, perhaps we could utilize some customized Java classes to perform these functions. As an alternative approach, as Endi alluded to, there is some ASN.1 code in Mozilla JSS, and speaking with Bob Relyea, we have been postulating on how much work would be involved to write JNI bindings via JSS to the ASN.1 encoders/decoders contained in NSS instead of moving this code to use java.nio.* classes. Theoretically, we may limit our performance issues in exchange for the extra work involved in making the effort to standardize on the NSS ASN.1 engine (although I don't know if this will resolve issues such as (3) noted above). -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Dec 21 02:43:30 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 20 Dec 2011 21:43:30 -0500 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EF14219.7030902@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> Message-ID: <4EF147D2.7010805@redhat.com> If the only questions are those of performance, than it is a non issue for now. On 12/20/2011 09:19 PM, Matthew Harmsen wrote: > On 12/16/11 17:24, Endi Sukma Dewata wrote: >> On 12/13/2011 4:25 PM, Adam Young wrote: >>> On 12/13/2011 02:03 PM, Andrew Wnuk wrote: >>>> Hopefully this patch was extremely well tested since it touches ASN.1 >>>> encoding. >>> Do you have a specific set of tests that we should be running? >> >> I just posted patch #5 which contains some unit tests for the >> converters. I've also updated and split patch #4 into #4-2a (renaming >> the files) and #4-2b (replacing the implementation). >> >> Patch #5 should be applied before #4-2a/b to make sure there's no >> regression. >> >> Mozilla JSS library also has some ASN.1 code, should we use them to >> implement the converters? >> >> http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/asn1/ >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > Endi, > > Andrew and I have been looking at these changes, and we have the > following concerns: > > (1) First of all, we looked up the bug where some of the sun.io.* > classes were deprecated (which mentions java.nio.charset and sun.nio.cs): > > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948149 > > (2) There appears to be considerable concern on performance > degradation when using "Charset": > > * http://stackoverflow.com/questions/2098137/fast-alternative-to-java-nio-charset-charset-decode-encode > * http://www.theserverside.com/discussions/thread.tss?thread_id=61270 > The article also states that the issue is being delat with in Java 7. We are standardizing on Java 7 for this release, so it should not be an issue. > (3) Additionally, there have been alterations in the CS code in the > past to fix problems encountered with the sun.io.* classes: > > * pki/base/util/src/netscape/security/util/ByteToCharPrintable.java > > Although we have not gotten to the unit tests, we suspect that these > will be great to have regardless of the direction that is decided > upon. However, due to our concerns regarding performance, could we > have some tests added (unit or a test tool) which obtain performance > results for the existing methods versus the proposed newer methods? > > If no discernable performance issues are encountered, most of these > changes appear to be acceptable -- the questionable one being the > replacing of the code that addressed issue (3) above. > > If there is an unacceptable degradation in performance, perhaps we > could utilize some customized Java classes to perform these functions. > As an alternative approach, as Endi alluded to, there is some ASN.1 > code in Mozilla JSS, and speaking with Bob Relyea, we have been > postulating on how much work would be involved to write JNI bindings > via JSS to the ASN.1 encoders/decoders contained in NSS instead of > moving this code to use java.nio.* classes. Theoretically, we may > limit our performance issues in exchange for the extra work involved > in making the effort to standardize on the NSS ASN.1 engine (although > I don't know if this will resolve issues such as (3) noted above). > > -- Matt I am not worried about performance at this point, it is way too premature. I am only concerned with correctness. The deprecated classes are going away, and we need an alternative to them. We will have a deliberate performance and tuning iteration once the code base has been restructured. If we find at that stage that there are still performance issues, we can look into writing a custom tuned solution, but based on overall system performance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Wed Dec 21 17:04:08 2011 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 21 Dec 2011 09:04:08 -0800 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EF147D2.7010805@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> <4EF147D2.7010805@redhat.com> Message-ID: <4EF21188.6030301@redhat.com> On 12/20/2011 06:43 PM, Adam Young wrote: > If the only questions are those of performance, than it is a non > issue for now. > > > > On 12/20/2011 09:19 PM, Matthew Harmsen wrote: >> On 12/16/11 17:24, Endi Sukma Dewata wrote: >>> On 12/13/2011 4:25 PM, Adam Young wrote: >>>> On 12/13/2011 02:03 PM, Andrew Wnuk wrote: >>>>> Hopefully this patch was extremely well tested since it touches ASN.1 >>>>> encoding. >>>> Do you have a specific set of tests that we should be running? >>> >>> I just posted patch #5 which contains some unit tests for the >>> converters. I've also updated and split patch #4 into #4-2a >>> (renaming the files) and #4-2b (replacing the implementation). >>> >>> Patch #5 should be applied before #4-2a/b to make sure there's no >>> regression. >>> >>> Mozilla JSS library also has some ASN.1 code, should we use them to >>> implement the converters? >>> >>> http://mxr.mozilla.org/mozilla/source/security/jss/org/mozilla/jss/asn1/ >>> >>> >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> Endi, >> >> Andrew and I have been looking at these changes, and we have the >> following concerns: >> >> (1) First of all, we looked up the bug where some of the sun.io.* >> classes were deprecated (which mentions java.nio.charset and sun.nio.cs): >> >> * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948149 >> >> (2) There appears to be considerable concern on performance >> degradation when using "Charset": >> >> * http://stackoverflow.com/questions/2098137/fast-alternative-to-java-nio-charset-charset-decode-encode >> * http://www.theserverside.com/discussions/thread.tss?thread_id=61270 >> > > > The article also states that the issue is being delat with in Java 7. and this is what we need to verify. > We are standardizing on Java 7 for this release, so it should not be > an issue. > >> (3) Additionally, there have been alterations in the CS code in the >> past to fix problems encountered with the sun.io.* classes: >> >> * pki/base/util/src/netscape/security/util/ByteToCharPrintable.java >> >> Although we have not gotten to the unit tests, we suspect that these >> will be great to have regardless of the direction that is decided >> upon. However, due to our concerns regarding performance, could we >> have some tests added (unit or a test tool) which obtain performance >> results for the existing methods versus the proposed newer methods? >> >> If no discernable performance issues are encountered, most of these >> changes appear to be acceptable -- the questionable one being the >> replacing of the code that addressed issue (3) above. >> >> If there is an unacceptable degradation in performance, perhaps we >> could utilize some customized Java classes to perform these >> functions. As an alternative approach, as Endi alluded to, there is >> some ASN.1 code in Mozilla JSS, and speaking with Bob Relyea, we have >> been postulating on how much work would be involved to write JNI >> bindings via JSS to the ASN.1 encoders/decoders contained in NSS >> instead of moving this code to use java.nio.* classes. >> Theoretically, we may limit our performance issues in exchange for >> the extra work involved in making the effort to standardize on the >> NSS ASN.1 engine (although I don't know if this will resolve issues >> such as (3) noted above). >> >> -- Matt > > I am not worried about performance at this point, Performance is not easily achievable and ignoring it is not the best practice for developing servers. > it is way too premature. I am only concerned with correctness. The > deprecated classes are going away, and we need an alternative to > them. We will have a deliberate performance and tuning iteration once > the code base has been restructured. If we find at that stage that > there are still performance issues, we can look into writing a custom > tuned solution, but based on overall system performance. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Dec 21 17:51:04 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 21 Dec 2011 11:51:04 -0600 Subject: [Pki-devel] [PATCH] 7 Fixed PKI_COMPONENT_LIST in all build scripts. Message-ID: <4EF21C88.80503@redhat.com> The PKI_COMPONENT_LIST has been modified to include the new test component to fix dependency issues. Ticket #3 Note: There seems to be an existing problem with the compose_pki_tps_packages. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0007-Fixed-PKI_COMPONENT_LIST-in-all-build-scripts.patch Type: text/x-patch Size: 5121 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 21 18:37:23 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 21 Dec 2011 12:37:23 -0600 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EF14219.7030902@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> Message-ID: <4EF22763.3080001@redhat.com> On 12/20/2011 8:19 PM, Matthew Harmsen wrote: > Andrew and I have been looking at these changes, and we have the > following concerns: > > (1) First of all, we looked up the bug where some of the sun.io.* > classes were deprecated (which mentions java.nio.charset and sun.nio.cs): > > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948149 The patch #4-2 a&b are addressing this issue by replacing the converters with charset encoders/decoders. I suppose when we use the java.nio.Charset API we will indirectly use the sun.nio.cs library. > (2) There appears to be considerable concern on performance degradation > when using "Charset": > > * http://stackoverflow.com/questions/2098137/fast-alternative-to-java-nio-charset-charset-decode-encode There isn't enough details to know what the actual problem is. Also the person asking was using Java 5, so it might not apply anymore in Java 7. > * http://www.theserverside.com/discussions/thread.tss?thread_id=61270 I think the above posting and the Java Code Geeks article (http://www.javacodegeeks.com/2010/11/java-best-practices-char-to-byte-and.html) are discussing about converting chars to bytes for ultra high performanace data serialization, not for encoding, so it doesn't apply to our case. Here's what the article says: Keep in mind that we are not converting between character encodings. For converting between character encodings you should stick with the ?classic? approaches using either the ?String.getBytes(charsetName)? or the NIO framework methods and utilities. While performance is a valid concern, I don't think the existing code has been much optimized for high performance. For example, the getCBC() and getBCC() do not cache the converter instances they create. > (3) Additionally, there have been alterations in the CS code in the past > to fix problems encountered with the sun.io.* classes: > > * pki/base/util/src/netscape/security/util/ByteToCharPrintable.java Do we know what problems are being fixed? I see one comment in the code about issue #359010 which will skip non-printable chars instead of reporting it. I suppose this is because there's no mechanism to ignore invalid input in sun.io.* packages. The Charset API provides an option to ignore invalid input, but we need to make sure we are using it correctly. Are there specific cases where we want to skip non-printable chars instead of throwing an exception? > Although we have not gotten to the unit tests, we suspect that these > will be great to have regardless of the direction that is decided upon. > However, due to our concerns regarding performance, could we have some > tests added (unit or a test tool) which obtain performance results for > the existing methods versus the proposed newer methods? I think we need to know the use cases that require high performance. Optimizing the converter alone might not be enough or worth the effort. Depending on the use case, there could be worse bottlenecks in other parts of the application. > If no discernable performance issues are encountered, most of these > changes appear to be acceptable -- the questionable one being the > replacing of the code that addressed issue (3) above. In order to address issue #3 we need to have a good test coverage. To verify the correctness, are there anything else that we need to include in the test case? > If there is an unacceptable degradation in performance, perhaps we could > utilize some customized Java classes to perform these functions. As an > alternative approach, as Endi alluded to, there is some ASN.1 code in > Mozilla JSS, and speaking with Bob Relyea, we have been postulating on > how much work would be involved to write JNI bindings via JSS to the > ASN.1 encoders/decoders contained in NSS instead of moving this code to > use java.nio.* classes. Theoretically, we may limit our performance > issues in exchange for the extra work involved in making the effort to > standardize on the NSS ASN.1 engine (although I don't know if this will > resolve issues such as (3) noted above). I checked the code, it looks like some of Mozilla's JSS code also relies on the Charset API. JNI calls have some overhead too, so we need to know how it's going to be used to avoid negative performance impact. -- Endi S. Dewata From alee at redhat.com Wed Dec 21 19:23:34 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Dec 2011 14:23:34 -0500 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EF22763.3080001@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> <4EF22763.3080001@redhat.com> Message-ID: <1324495415.4868.25.camel@aleeredhat.laptop> > > If there is an unacceptable degradation in performance, perhaps we could > > utilize some customized Java classes to perform these functions. As an > > alternative approach, as Endi alluded to, there is some ASN.1 code in > > Mozilla JSS, and speaking with Bob Relyea, we have been postulating on > > how much work would be involved to write JNI bindings via JSS to the > > ASN.1 encoders/decoders contained in NSS instead of moving this code to > > use java.nio.* classes. Theoretically, we may limit our performance > > issues in exchange for the extra work involved in making the effort to > > standardize on the NSS ASN.1 engine (although I don't know if this will > > resolve issues such as (3) noted above). > > I checked the code, it looks like some of Mozilla's JSS code also relies > on the Charset API. JNI calls have some overhead too, so we need to know > how it's going to be used to avoid negative performance impact. > I agree the performance is a concern, and is something that we should keep in mind, but it is not clear that differences in performance in these classes will degrade the performance of the system. The only way to determine where the system is really spending its time is by running it through a profiler and analyzing the results. We may find that the server spends comparatively no time in this code. On the other hand, we have a compelling reason to change these classes. The classes are deprecated - and will go away - and then everything will stop working. I suggest that we review this patch for correctness. Is the encoding correct? Do the unit tests cover enough - or have the right inputs to validate the correctness of the conversion? It seems like there were situations like (3) where perhaps more testing is required. And we should schedule a performance testing and profiling task for next year. We will always have the 8.x code as a benchmark. If at that time, we find that these classes cause performance problems, we can always look into custom classes or maybe JSS code. It seems to me that talking about custom classes before having any profiling data is putting the cart before the horse. Ade From alee at redhat.com Wed Dec 21 19:39:48 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Dec 2011 14:39:48 -0500 Subject: [Pki-devel] [PATCH] 7 Fixed PKI_COMPONENT_LIST in all build scripts. In-Reply-To: <4EF21C88.80503@redhat.com> References: <4EF21C88.80503@redhat.com> Message-ID: <1324496388.4868.26.camel@aleeredhat.laptop> ACK On Wed, 2011-12-21 at 11:51 -0600, Endi Sukma Dewata wrote: > The PKI_COMPONENT_LIST has been modified to include the new test > component to fix dependency issues. > > Ticket #3 > > Note: There seems to be an existing problem with the > compose_pki_tps_packages. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jdennis at redhat.com Wed Dec 21 19:42:02 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 Dec 2011 14:42:02 -0500 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <1324495415.4868.25.camel@aleeredhat.laptop> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> <4EF22763.3080001@redhat.com> <1324495415.4868.25.camel@aleeredhat.laptop> Message-ID: <4EF2368A.2060601@redhat.com> On 12/21/2011 02:23 PM, Ade Lee wrote: > It seems to me that talking about custom classes before having any > profiling data is putting the cart before the horse. +1 Correctness comes first, do not optimize without profiling data (assumptions about performance are usually incorrect), then only optimize based on profiling data and only for cases that matter, do not give up code simplicity and robustness unless there is a real valid case that demands it. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From awnuk at redhat.com Wed Dec 21 20:31:04 2011 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 21 Dec 2011 12:31:04 -0800 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <1324495415.4868.25.camel@aleeredhat.laptop> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> <4EF22763.3080001@redhat.com> <1324495415.4868.25.camel@aleeredhat.laptop> Message-ID: <4EF24208.50802@redhat.com> On 12/21/2011 11:23 AM, Ade Lee wrote: > >>> If there is an unacceptable degradation in performance, perhaps we could >>> utilize some customized Java classes to perform these functions. As an >>> alternative approach, as Endi alluded to, there is some ASN.1 code in >>> Mozilla JSS, and speaking with Bob Relyea, we have been postulating on >>> how much work would be involved to write JNI bindings via JSS to the >>> ASN.1 encoders/decoders contained in NSS instead of moving this code to >>> use java.nio.* classes. Theoretically, we may limit our performance >>> issues in exchange for the extra work involved in making the effort to >>> standardize on the NSS ASN.1 engine (although I don't know if this will >>> resolve issues such as (3) noted above). >> >> I checked the code, it looks like some of Mozilla's JSS code also relies >> on the Charset API. JNI calls have some overhead too, so we need to know >> how it's going to be used to avoid negative performance impact. >> > > I agree the performance is a concern, and is something that we should > keep in mind, but it is not clear that differences in performance in > these classes will degrade the performance of the system. The only way > to determine where the system is really spending its time is by running > it through a profiler and analyzing the results. We may find that the > server spends comparatively no time in this code. I think "may" is a proper keyword here. If someone, calls "Charset API" a "bottleneck" that should be good enough warning to do some simple testing to verify it. > > > On the other hand, we have a compelling reason to change these classes. > The classes are deprecated - and will go away - and then everything will > stop working. > > I suggest that we review this patch for correctness. I think Matt's email was clear. This patch is fine but we had 3 concerns which were listed in his email. > Is the encoding > correct? There is no simple test to prove this or to replace years of compatibility testing (case like (3) can be good example of this). > Do the unit tests cover enough - or have the right inputs to > validate the correctness of the conversion? It seems like there were > situations like (3) where perhaps more testing is required. Agreed, there was always apparent reason for fixes like (3). > > > And we should schedule a performance testing and profiling task for next > year. We will always have the 8.x code as a benchmark. If at that > time, we find that these classes cause performance problems, we can > always look into custom classes or maybe JSS code. > > It seems to me that talking about custom classes before having any > profiling data is putting the cart before the horse. > > Ade > > From edewata at redhat.com Wed Dec 21 21:16:02 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 21 Dec 2011 15:16:02 -0600 Subject: [Pki-devel] [PATCH] 7 Fixed PKI_COMPONENT_LIST in all build scripts. In-Reply-To: <1324496388.4868.26.camel@aleeredhat.laptop> References: <4EF21C88.80503@redhat.com> <1324496388.4868.26.camel@aleeredhat.laptop> Message-ID: <4EF24C92.8030208@redhat.com> On 12/21/2011 1:39 PM, Ade Lee wrote: > ACK Pushed to master. -- Endi S. Dewata From alee at redhat.com Wed Dec 21 21:56:33 2011 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Dec 2011 16:56:33 -0500 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <4EF24208.50802@redhat.com> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> <4EF22763.3080001@redhat.com> <1324495415.4868.25.camel@aleeredhat.laptop> <4EF24208.50802@redhat.com> Message-ID: <1324504594.4868.36.camel@aleeredhat.laptop> On Wed, 2011-12-21 at 12:31 -0800, Andrew Wnuk wrote: > On 12/21/2011 11:23 AM, Ade Lee wrote: > > > >>> If there is an unacceptable degradation in performance, perhaps we could > >>> utilize some customized Java classes to perform these functions. As an > >>> alternative approach, as Endi alluded to, there is some ASN.1 code in > >>> Mozilla JSS, and speaking with Bob Relyea, we have been postulating on > >>> how much work would be involved to write JNI bindings via JSS to the > >>> ASN.1 encoders/decoders contained in NSS instead of moving this code to > >>> use java.nio.* classes. Theoretically, we may limit our performance > >>> issues in exchange for the extra work involved in making the effort to > >>> standardize on the NSS ASN.1 engine (although I don't know if this will > >>> resolve issues such as (3) noted above). > >> > >> I checked the code, it looks like some of Mozilla's JSS code also relies > >> on the Charset API. JNI calls have some overhead too, so we need to know > >> how it's going to be used to avoid negative performance impact. > >> > > > > I agree the performance is a concern, and is something that we should > > keep in mind, but it is not clear that differences in performance in > > these classes will degrade the performance of the system. The only way > > to determine where the system is really spending its time is by running > > it through a profiler and analyzing the results. We may find that the > > server spends comparatively no time in this code. > > I think "may" is a proper keyword here. If someone, calls "Charset API" > a "bottleneck" that should be good enough warning to do some simple > testing to verify it. > Lets say we do a simple test and the encoding takes 3 ms instead of 1 ms to complete. What then? Do we reject the patch? Do we embark on a process whereby we investigate custom code or look into JSS functions? No - we do not. Why? Because we have no idea whether this is even a bottleneck for our server. Just because it was a bottleneck for someone else for some random app - does not mean it will be the same for us. It may end up being a huge bottleneck - or it may be completely irrelevant. We do not know - and we will not know - until we do profiling. Without profiling information, we are optimizing in the dark, and we will very likely spend a lot of wasted time optimizing the wrong things. > > > > > > On the other hand, we have a compelling reason to change these classes. > > The classes are deprecated - and will go away - and then everything will > > stop working. > > > > I suggest that we review this patch for correctness. > > I think Matt's email was clear. This patch is fine but we had 3 concerns > which were listed in his email. > > > Is the encoding > > correct? > > There is no simple test to prove this or to replace years of > compatibility testing (case like (3) can be good example of this). > > > Do the unit tests cover enough - or have the right inputs to > > validate the correctness of the conversion? It seems like there were > > situations like (3) where perhaps more testing is required. > > Agreed, there was always apparent reason for fixes like (3). > > > > > > > And we should schedule a performance testing and profiling task for next > > year. We will always have the 8.x code as a benchmark. If at that > > time, we find that these classes cause performance problems, we can > > always look into custom classes or maybe JSS code. > > > > It seems to me that talking about custom classes before having any > > profiling data is putting the cart before the horse. > > > > Ade > > > > > From awnuk at redhat.com Wed Dec 21 22:11:37 2011 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 21 Dec 2011 14:11:37 -0800 Subject: [Pki-devel] [PATCH] 4 Replaced byte-to-char & char-to-byte converters. In-Reply-To: <1324504594.4868.36.camel@aleeredhat.laptop> References: <4EE78F94.6080705@redhat.com> <4EE7A164.5030709@redhat.com> <4EE7D0D9.1090400@redhat.com> <4EEBEF4D.5060402@redhat.com> <4EF14219.7030902@redhat.com> <4EF22763.3080001@redhat.com> <1324495415.4868.25.camel@aleeredhat.laptop> <4EF24208.50802@redhat.com> <1324504594.4868.36.camel@aleeredhat.laptop> Message-ID: <4EF25999.6060302@redhat.com> On 12/21/2011 01:56 PM, Ade Lee wrote: > On Wed, 2011-12-21 at 12:31 -0800, Andrew Wnuk wrote: >> On 12/21/2011 11:23 AM, Ade Lee wrote: >>>>> If there is an unacceptable degradation in performance, perhaps we could >>>>> utilize some customized Java classes to perform these functions. As an >>>>> alternative approach, as Endi alluded to, there is some ASN.1 code in >>>>> Mozilla JSS, and speaking with Bob Relyea, we have been postulating on >>>>> how much work would be involved to write JNI bindings via JSS to the >>>>> ASN.1 encoders/decoders contained in NSS instead of moving this code to >>>>> use java.nio.* classes. Theoretically, we may limit our performance >>>>> issues in exchange for the extra work involved in making the effort to >>>>> standardize on the NSS ASN.1 engine (although I don't know if this will >>>>> resolve issues such as (3) noted above). >>>> I checked the code, it looks like some of Mozilla's JSS code also relies >>>> on the Charset API. JNI calls have some overhead too, so we need to know >>>> how it's going to be used to avoid negative performance impact. >>>> >>> I agree the performance is a concern, and is something that we should >>> keep in mind, but it is not clear that differences in performance in >>> these classes will degrade the performance of the system. The only way >>> to determine where the system is really spending its time is by running >>> it through a profiler and analyzing the results. We may find that the >>> server spends comparatively no time in this code. >> I think "may" is a proper keyword here. If someone, calls "Charset API" >> a "bottleneck" that should be good enough warning to do some simple >> testing to verify it. >> > Lets say we do a simple test and the encoding takes 3 ms instead of 1 ms > to complete. What then? Do we reject the patch? Do we embark on a > process whereby we investigate custom code or look into JSS functions? > > No - we do not. Why? Because we have no idea whether this is even a > bottleneck for our server. Just because it was a bottleneck for someone > else for some random app - does not mean it will be the same for us. It > may end up being a huge bottleneck - or it may be completely irrelevant. > We do not know - and we will not know - until we do profiling. > > Without profiling information, we are optimizing in the dark, and we > will very likely spend a lot of wasted time optimizing the wrong things. I think the point is to check if this issue is real or not. This does not require any profiling or optimization just a simple test. > >>> >>> On the other hand, we have a compelling reason to change these classes. >>> The classes are deprecated - and will go away - and then everything will >>> stop working. >>> >>> I suggest that we review this patch for correctness. >> I think Matt's email was clear. This patch is fine but we had 3 concerns >> which were listed in his email. >> >>> Is the encoding >>> correct? >> There is no simple test to prove this or to replace years of >> compatibility testing (case like (3) can be good example of this). >> >>> Do the unit tests cover enough - or have the right inputs to >>> validate the correctness of the conversion? It seems like there were >>> situations like (3) where perhaps more testing is required. >> Agreed, there was always apparent reason for fixes like (3). >> >>> >>> And we should schedule a performance testing and profiling task for next >>> year. We will always have the 8.x code as a benchmark. If at that >>> time, we find that these classes cause performance problems, we can >>> always look into custom classes or maybe JSS code. >>> >>> It seems to me that talking about custom classes before having any >>> profiling data is putting the cart before the horse. >>> >>> Ade >>> >>> > From ayoung at redhat.com Thu Dec 22 18:08:42 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 22 Dec 2011 13:08:42 -0500 Subject: [Pki-devel] [PATCH] typesafety patches Message-ID: <4EF3722A.1080708@redhat.com> These have been rebased on top of master and might conflict with previously submitted patches. These should all all be relatively independent, but it is possible that some of the later patches require earlier patches in order to apply. Please indicate the patch number in any ACK/NACK messages. -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0028-Removal-of-unused-private-methods.patch Type: text/x-patch Size: 3259 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0029-gitignore.patch Type: text/x-patch Size: 896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0030-TreeSet.patch Type: text/x-patch Size: 3288 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0031-Unreachable-Catch-clauses.patch Type: text/x-patch Size: 7504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0032-util-type-safety-cleanup.patch Type: text/x-patch Size: 60335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0033-type-safety-cleanup-in-common.patch Type: text/x-patch Size: 9455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0034-Type-safety-for-ACLs.patch Type: text/x-patch Size: 5409 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0035-Type-safety-for-CMS-and-by-extension-much-of-common.patch Type: text/x-patch Size: 34907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0036-type-safety-for-certserv.authenticator.patch Type: text/x-patch Size: 10472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0037-type-safety-for-certserv.authorization.patch Type: text/x-patch Size: 17968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0038-type-safety-for-certserv.base.patch Type: text/x-patch Size: 57982 bytes Desc: not available URL: From alee at redhat.com Thu Dec 22 20:22:41 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 22 Dec 2011 15:22:41 -0500 Subject: [Pki-devel] [PATCH] typesafety patches In-Reply-To: <4EF3722A.1080708@redhat.com> References: <4EF3722A.1080708@redhat.com> Message-ID: <1324585362.4868.45.camel@aleeredhat.laptop> 28 - ACK 29 - ACK 30 - ACK - but change the description. This has nothing to do with TreeSet 31 - ACK 32 - For the most part - ACK. RevokedCertImpl.java looks like it has been reformatted though -- which is obscuring the real changes in the file. Please resubmit with just the relevant changes in that file. Continuing with the rest .. Ade On Thu, 2011-12-22 at 13:08 -0500, Adam Young wrote: > These have been rebased on top of master and might conflict with > previously submitted patches. These should all all be relatively > independent, but it is possible that some of the later patches require > earlier patches in order to apply. Please indicate the patch number in > any ACK/NACK messages. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Dec 22 21:01:16 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 22 Dec 2011 16:01:16 -0500 Subject: [Pki-devel] [PATCH] typesafety patches In-Reply-To: <1324585362.4868.45.camel@aleeredhat.laptop> References: <4EF3722A.1080708@redhat.com> <1324585362.4868.45.camel@aleeredhat.laptop> Message-ID: <1324587676.4868.50.camel@aleeredhat.laptop> 33 - ACK 34 - ACK 35 - ACK 36- ACK 37 - ACK 38 - In AuthAdminServlet.java , a suppress warnings annotation is placed before addAuthMgrPlugin(). Can it be moved closer to the code causing the warnings? - Why has the return for the put() method in SourceConfigStore and PropConfigStore (and the corresponding interfaces been changed from void to string? What is supposed to be returned here? Ade On Thu, 2011-12-22 at 15:22 -0500, Ade Lee wrote: > 28 - ACK > 29 - ACK > 30 - ACK - but change the description. This has nothing to do with > TreeSet > 31 - ACK > 32 - For the most part - ACK. RevokedCertImpl.java looks like it has > been reformatted though -- which is obscuring the real changes in the > file. Please resubmit with just the relevant changes in that file. > > Continuing with the rest .. > > Ade > > On Thu, 2011-12-22 at 13:08 -0500, Adam Young wrote: > > These have been rebased on top of master and might conflict with > > previously submitted patches. These should all all be relatively > > independent, but it is possible that some of the later patches require > > earlier patches in order to apply. Please indicate the patch number in > > any ACK/NACK messages. > > _______________________________________________ > > 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 ayoung at redhat.com Thu Dec 22 21:41:27 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 22 Dec 2011 16:41:27 -0500 Subject: [Pki-devel] [PATCH] typesafety patches In-Reply-To: <1324587676.4868.50.camel@aleeredhat.laptop> References: <4EF3722A.1080708@redhat.com> <1324585362.4868.45.camel@aleeredhat.laptop> <1324587676.4868.50.camel@aleeredhat.laptop> Message-ID: <4EF3A407.5090200@redhat.com> On 12/22/2011 04:01 PM, Ade Lee wrote: > 33 - ACK > 34 - ACK > 35 - ACK > 36- ACK > 37 - ACK > 38 > - In AuthAdminServlet.java , a suppress warnings annotation is placed > before addAuthMgrPlugin(). Can it be moved closer to the code causing > the warnings? Yep.. done > - Why has the return for the put() method in SourceConfigStore and > PropConfigStore (and the corresponding interfaces been changed from void > to string? What is supposed to be returned here? SourceConfigStore extends SimpleProperties SimpleProperties extends Hashtable So it has to return a string. Config is basically properties files: string to string. > > Ade > > On Thu, 2011-12-22 at 15:22 -0500, Ade Lee wrote: >> 28 - ACK >> 29 - ACK >> 30 - ACK - but change the description. This has nothing to do with >> TreeSet Will change it to "type safety in CMSCRLExtensions and PublisherProcessor" >> 31 - ACK >> 32 - For the most part - ACK. RevokedCertImpl.java looks like it has >> been reformatted though -- which is obscuring the real changes in the >> file. Please resubmit with just the relevant changes in that file. Resubmitted >> >> Continuing with the rest .. >> >> Ade >> >> On Thu, 2011-12-22 at 13:08 -0500, Adam Young wrote: >>> These have been rebased on top of master and might conflict with >>> previously submitted patches. These should all all be relatively >>> independent, but it is possible that some of the later patches require >>> earlier patches in order to apply. Please indicate the patch number in >>> any ACK/NACK messages. >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0038-1-type-safety-for-certserv.base.patch Type: text/x-patch Size: 58065 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0032-1-util-type-safety-cleanup.patch Type: text/x-patch Size: 37721 bytes Desc: not available URL: From ayoung at redhat.com Thu Dec 22 22:18:12 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 22 Dec 2011 17:18:12 -0500 Subject: [Pki-devel] [PATCH] typesafety patches In-Reply-To: <4EF3A407.5090200@redhat.com> References: <4EF3722A.1080708@redhat.com> <1324585362.4868.45.camel@aleeredhat.laptop> <1324587676.4868.50.camel@aleeredhat.laptop> <4EF3A407.5090200@redhat.com> Message-ID: <4EF3ACA4.1020605@redhat.com> On 12/22/2011 04:41 PM, Adam Young wrote: > On 12/22/2011 04:01 PM, Ade Lee wrote: >> 33 - ACK >> 34 - ACK >> 35 - ACK >> 36- ACK >> 37 - ACK >> 38 >> - In AuthAdminServlet.java , a suppress warnings annotation is placed >> before addAuthMgrPlugin(). Can it be moved closer to the code causing >> the warnings? > Yep.. done > >> - Why has the return for the put() method in SourceConfigStore and >> PropConfigStore (and the corresponding interfaces been changed from void >> to string? What is supposed to be returned here? > SourceConfigStore extends SimpleProperties > > SimpleProperties extends Hashtable > > So it has to return a string. Config is basically properties files: > string to string. > > >> >> Ade >> >> On Thu, 2011-12-22 at 15:22 -0500, Ade Lee wrote: >>> 28 - ACK >>> 29 - ACK >>> 30 - ACK - but change the description. This has nothing to do with >>> TreeSet > Will change it to "type safety in CMSCRLExtensions and > PublisherProcessor" > > >>> 31 - ACK >>> 32 - For the most part - ACK. RevokedCertImpl.java looks like it has >>> been reformatted though -- which is obscuring the real changes in the >>> file. Please resubmit with just the relevant changes in that file. > > Resubmitted >>> >>> Continuing with the rest .. >>> >>> Ade >>> >>> On Thu, 2011-12-22 at 13:08 -0500, Adam Young wrote: >>>> These have been rebased on top of master and might conflict with >>>> previously submitted patches. These should all all be relatively >>>> independent, but it is possible that some of the later patches >>>> require >>>> earlier patches in order to apply. Please indicate the patch >>>> number in >>>> any ACK/NACK messages. >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Final ACK in IRC by Ade Lee. Pushed to master -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 23 02:09:17 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 22 Dec 2011 21:09:17 -0500 Subject: [Pki-devel] [PATCH] more typesafety changes Message-ID: <4EF3E2CD.1070507@redhat.com> This series can all be applied prior to the simple name changes. They should be noncontraversial. -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0039-typesafety-certserv-and-cmscore.patch Type: text/x-patch Size: 19299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0040-typesafety-cron-and-jobscheduler.patch Type: text/x-patch Size: 8434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0041-typesafety-db-and-logging.patch Type: text/x-patch Size: 36360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0042-Typesafety-for-certsrv.kra.patch Type: text/x-patch Size: 13174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0043-type-safety-certserv-cms-and-cmscore.patch Type: text/x-patch Size: 104921 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0044-typesafe-returns-on-IDBSession-for-VirtualList.patch Type: text/x-patch Size: 15120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0045-typesafety-ACL-Impls.patch Type: text/x-patch Size: 21555 bytes Desc: not available URL: From alee at redhat.com Thu Dec 29 20:31:33 2011 From: alee at redhat.com (Ade Lee) Date: Thu, 29 Dec 2011 15:31:33 -0500 Subject: [Pki-devel] [PATCH] more typesafety changes In-Reply-To: <4EF3E2CD.1070507@redhat.com> References: <4EF3E2CD.1070507@redhat.com> Message-ID: <1325190694.4868.52.camel@aleeredhat.laptop> On Thu, 2011-12-22 at 21:09 -0500, Adam Young wrote: > This series can all be applied prior to the simple name changes. They > should be noncontraversial. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel 39, 40, 41,42, 44, 45 - ack 43 -- Why are IPublshRuleSet and ILdapCertMapper being deleted? Ade