From jmagne at redhat.com Sat Jun 1 03:20:51 2013 From: jmagne at redhat.com (John Magne) Date: Fri, 31 May 2013 23:20:51 -0400 (EDT) Subject: [Pki-devel] Fwd: Review Request Bug 963073 - rhcs81 tps crash for CN over than 64 bytes In-Reply-To: <1936222869.10469818.1369849278677.JavaMail.root@redhat.com> References: <1936222869.10469818.1369849278677.JavaMail.root@redhat.com> Message-ID: <523109790.12552224.1370056851056.JavaMail.root@redhat.com> Please review the additional patch included: subject.diff This is a fix to the CA for this same issue that will prevent enrollments with illegal attributes contained within the Subject Name for an incoming request. ----- Forwarded Message ----- From: "John Magne" To: "pki-devel" Sent: Wednesday, May 29, 2013 10:41:18 AM Subject: Review Request Bug 963073 - rhcs81 tps crash for CN over than 64 bytes Please review attached patch. Fix solves a crash when a certificate to be displayed contains too many characters in one of its fields. -------------- next part -------------- A non-text attachment was scrubbed... Name: subject.diff Type: text/x-patch Size: 4335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tps-ui-fix.patch Type: text/x-patch Size: 1305 bytes Desc: not available URL: From cfu at redhat.com Sat Jun 1 04:45:31 2013 From: cfu at redhat.com (Christina Fu) Date: Fri, 31 May 2013 21:45:31 -0700 Subject: [Pki-devel] Fwd: Review Request Bug 963073 - rhcs81 tps crash for CN over than 64 bytes In-Reply-To: <523109790.12552224.1370056851056.JavaMail.root@redhat.com> References: <1936222869.10469818.1369849278677.JavaMail.root@redhat.com> <523109790.12552224.1370056851056.JavaMail.root@redhat.com> Message-ID: <51A97C6B.2060908@redhat.com> On 05/31/2013 08:20 PM, John Magne wrote: > Please review the additional patch included: subject.diff > > This is a fix to the CA for this same issue that will prevent enrollments with illegal attributes contained within the Subject Name for an incoming request. > > ----- Forwarded Message ----- > From: "John Magne" > To: "pki-devel" > Sent: Wednesday, May 29, 2013 10:41:18 AM > Subject: Review Request Bug 963073 - rhcs81 tps crash for CN over than 64 bytes > > > Please review attached patch. Fix solves a crash when a certificate to be displayed contains too many characters in one of its fields. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Looks good overall. One thing to consider is to check for all fields before throwing an exception listing all violated components. Otherwise ack. Christina -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Jun 3 16:38:08 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Jun 2013 11:38:08 -0500 Subject: [Pki-devel] [PATCH] 264 Added support to backup folders during upgrade. Message-ID: <51ACC670.5010202@redhat.com> The upgrade framework has been updated to support backup and restore operations for folders and their contents. Ticket #583 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0264-Added-support-to-backup-folders-during-upgrade.patch Type: text/x-patch Size: 13540 bytes Desc: not available URL: From edewata at redhat.com Mon Jun 3 23:10:10 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Jun 2013 18:10:10 -0500 Subject: [Pki-devel] [PATCH] 252-260 Preparation for Tomcat-based TPS In-Reply-To: <51A77C27.3060309@redhat.com> References: <51A50DBE.1010209@redhat.com> <51A6A253.3050405@redhat.com> <51A77C27.3060309@redhat.com> Message-ID: <51AD2252.1000103@redhat.com> >> *PATCHES 0259 and 0260 were NOT tested as they immediately failed >> 'pkispawn' with the following error:* >> >> pkispawn : ERROR ....... KeyError: Master dictionary is >> missing the key called ''pki_ca_hostname''! >> Traceback (most recent call last): >> File "/sbin/pkispawn", line 420, in >> main(sys.argv) >> File "/sbin/pkispawn", line 319, in main >> parser.compose_pki_master_dictionary() >> File >> "/usr/lib/python2.7/site-packages/pki/deployment/pkiparser.py", line >> 658, in compose_pki_master_dictionary >> config.pki_master_dict['pki_ca_hostname'] >> KeyError: 'pki_ca_hostname' >> >> Consequently, these two patches were backed-out so that the other >> patches could be successfully tested. > > New patches attached. The default parameters have been added to > default.cfg. ACKed by Matt. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Jun 3 23:10:39 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Jun 2013 18:10:39 -0500 Subject: [Pki-devel] [PATCH] 261 Fixed hard-coded server certificate nickname. In-Reply-To: <51A77C49.8000702@redhat.com> References: <51A77C49.8000702@redhat.com> Message-ID: <51AD226F.7070807@redhat.com> On 5/30/2013 11:20 AM, Endi Sukma Dewata wrote: > Previously the server certificate name was partially hard-coded as > "Server-Cert cert-[PKI_INSTANCE_NAME]". Now in Tomcat-based subsystems > it can be fully configured using pki_ssl_server_nickname parameter. > In Apache-based subsystems it's left unchanged. > > Unused copies of serverCertNick.conf have been removed. > > Ticket #631 ACKed by Matt. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Jun 4 16:44:26 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Jun 2013 11:44:26 -0500 Subject: [Pki-devel] [PATCH] 261 Fixed hard-coded server certificate nickname. In-Reply-To: <51AD226F.7070807@redhat.com> References: <51A77C49.8000702@redhat.com> <51AD226F.7070807@redhat.com> Message-ID: <51AE196A.8090301@redhat.com> On 6/3/2013 6:10 PM, Endi Sukma Dewata wrote: > On 5/30/2013 11:20 AM, Endi Sukma Dewata wrote: >> Previously the server certificate name was partially hard-coded as >> "Server-Cert cert-[PKI_INSTANCE_NAME]". Now in Tomcat-based subsystems >> it can be fully configured using pki_ssl_server_nickname parameter. >> In Apache-based subsystems it's left unchanged. >> >> Unused copies of serverCertNick.conf have been removed. >> >> Ticket #631 > > ACKed by Matt. Pushed to master. Rebased and pushed to 10.0.x branch. -- Endi S. Dewata From akoneru at redhat.com Tue Jun 4 22:16:21 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Tue, 04 Jun 2013 18:16:21 -0400 Subject: [Pki-devel] [PATCH] 60 Continuation to patch 59 - Fixing pylint errors Message-ID: <1370384181.11363.2.camel@akoneru.redhat.com> Please review the patch which fixes issues related to application of PEP 8 standards to the python code, raised in pylint scan. Should be applied over patch 59, which is also attached here. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0060-Adding-PEP8-standards-to-python-code.patch Type: text/x-patch Size: 250048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0059-Code-cleanup-and-fixing-Pylint-errors.patch Type: text/x-patch Size: 114295 bytes Desc: not available URL: From jmagne at redhat.com Tue Jun 4 22:55:39 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 4 Jun 2013 18:55:39 -0400 (EDT) Subject: [Pki-devel] [PATCH] 262 Added Tomcat-based TPS instance. In-Reply-To: <51A7C9BD.1000302@redhat.com> References: <51A79907.3070807@redhat.com> <51A7C9BD.1000302@redhat.com> Message-ID: <665441867.14325964.1370386539766.JavaMail.root@redhat.com> ACK Just went through the list of stuff quickly. Appears to be a fine template of files for a new Java TPS instance. ----- Original Message ----- > From: "Endi Sukma Dewata" > To: "pki-devel" > Sent: Thursday, May 30, 2013 2:50:53 PM > Subject: Re: [Pki-devel] [PATCH] 262 Added Tomcat-based TPS instance. > > On 5/30/2013 1:23 PM, Endi Sukma Dewata wrote: > > The build and deployment tools have been modified to support creating > > a basic Tomcat instance to run TPS. New configuration and template > > files for TPS have been copied from another Tomcat subsystem. The TPS > > functionality itself will be added in future patches. > > > > Ticket #526 > > To set up the TPS instance you only need to create CA, no need to create > TKS/KRA for now. Attached are sample configuration files. > > % pkispawn -f ca.cfg -s CA > % pkispawn -f tps.cfg -s TPS > > -- > Endi S. Dewata > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Tue Jun 4 22:56:46 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 4 Jun 2013 18:56:46 -0400 (EDT) Subject: [Pki-devel] [PATCH] 263 Added TPS servlet. In-Reply-To: <51A79928.8080609@redhat.com> References: <51A79928.8080609@redhat.com> Message-ID: <227904603.14326184.1370386606486.JavaMail.root@redhat.com> ACK Looks good. Just for fun you might want to add a bit to the demo so that it returns an error APDU back to the client at the end to see if the client can process it. ----- Original Message ----- > From: "Endi Sukma Dewata" > To: "pki-devel" > Sent: Thursday, May 30, 2013 11:23:36 AM > Subject: [Pki-devel] [PATCH] 263 Added TPS servlet. > > A basic TPS servlet has been added to demonstrate sending and > receiving TPS messages using chunked encoding. > > The servlet can be tested using the attached tps-test.sh. See the output > in /var/log/pki//catalina.out. > > -- > Endi S. Dewata > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Wed Jun 5 18:38:41 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Wed, 05 Jun 2013 14:38:41 -0400 Subject: [Pki-devel] [PATCH] 61 Change how installation summary is displayed. Ticket#599 - Dogtag 10.0.3 Message-ID: <1370457521.8342.3.camel@akoneru.redhat.com> Please review the patch which shows the installation summary, only when pki_skip_configuration is not True. Also the client database details are shown only when pki_client_database_purge=False. The configuration url is already shown when pki_skip_configuration = true. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0061-Changes-to-the-displayed-installation-summary.patch Type: text/x-patch Size: 13900 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 6 00:44:22 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Jun 2013 19:44:22 -0500 Subject: [Pki-devel] [PATCH] 58-2 Minor fixes for patch 58 In-Reply-To: <1370028041.4953.2.camel@akoneru.redhat.com> References: <1369155772.8356.2.camel@akoneru.redhat.com> <519FA9C6.8060104@redhat.com> <1370028041.4953.2.camel@akoneru.redhat.com> Message-ID: <51AFDB66.8080806@redhat.com> On 5/31/2013 2:20 PM, Abhishek Koneru wrote: >> 1. In drmclient.py, in http_request() and https_request() suppose the >> NSSConnection supports Context Manager we could use 'with' statement >> too. Could you check? >> >> http://docs.python.org/2/reference/compound_stmts.html#with >> >> 2. Also in http_request() and https_request(), I'm not sure if we really >> need to wrap the original exception, but that's a separate issue. If we >> can remove it we can use 'with' here, or at least nest it. > > Both NSSConnection and httplib.HTTPConnection do not support Context > Manager. Hence, no changes made here. OK. >> 3. In kra.__init__() the self.password = '' assignment can be moved >> before open() so in case of error it will be blank already. This way we >> can use the 'with' statement. > -- Nested the with in the try-except block There's a trailing space on line 419. Please fix before push. >> 4. In pkimanifest.py, in file.write() and read() the error logging >> should really be done by the caller. But here at least we can use 'with' >> nested inside the 'try-except'. > used with for file operations >> > Please review the attached patch. ACK. -- Endi S. Dewata From mharmsen at redhat.com Thu Jun 6 01:30:19 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 05 Jun 2013 18:30:19 -0700 Subject: [Pki-devel] [PATCH] Updated man pages Message-ID: <51AFE62B.9030403@redhat.com> Please review the attached patch for Dogtag 10.0.3 which resolves the following TRAC tickets: * TRAC Ticket #606 - add restart / start at boot info to pkispawn man page * TRAC Ticket #610 - Document limitation in using GUI install * TRAC Ticket #629 - Package ownership of '/usr/share/pki/etc/' directory The changes for Dogtag 10.1 are identical. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20130605-Updated-man-pages-10.0.3.patch Type: text/x-patch Size: 8554 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 6 02:38:47 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Jun 2013 21:38:47 -0500 Subject: [Pki-devel] [PATCH] 59 Fixing errors reported in Pylint Code analysis Ticket #316 - Part 1 In-Reply-To: <1370032689.4953.7.camel@akoneru.redhat.com> References: <1370032689.4953.7.camel@akoneru.redhat.com> Message-ID: <51AFF637.8000807@redhat.com> On 5/31/2013 3:38 PM, Abhishek Koneru wrote: > Please review the patch which fixes a few errors reported by pylint in > dogtag's python code. > > Also find attached the remaining errors to be fixed. Will submit a > detailed report in my next mail. > > How i used pylint: > > -- Installed pki packages. > -- Executed the following command - > cd /usr/lib/python2.7/sitepackages; pylint -E --include-ids=y pki/ > pki/deployment/ pki/server/ `which pkispawn` `which pkidestroy` `which > pki-upgrade` `which pki-server-upgrade` > > --Abhishek Looking at the pkihelper.py again, I'm not sure if this is the right approach. In the original code the classes are instantiated into global objects and we're calling the methods of these objects like this: uid = identity.get_uid() In the new code the methods are converted into static methods: uid = Identity.get_uid() The problem is many of these methods actually depend on other global objects such as 'master', so we haven't really removed the dependency on global variables. I'm thinking we probably should encapsulate the global objects into an object that we can pass around, then we access them as local variables. For example, in pkispawn we generate the master object and put it in a Deployer object. Then we pass the deployer object to the scriptlets. deployer = pki.server.Deployer(master) instance = scriptlet.PkiScriptlet() instance.spawn(deployer) The Deployer class will have methods that generate the old global objects and we pass the master into those objects: def get_identity(self): return Identity(master) In the scriptlets we can call the methods this way: identity = deployer.get_identity() uid = identity.get_uid() What do you think? If we do this, I'd suggest we do the conversion one global object at a time so it's easier to review. -- Endi S. Dewata From edewata at redhat.com Thu Jun 6 02:42:31 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Jun 2013 21:42:31 -0500 Subject: [Pki-devel] [PATCH] 60 Continuation to patch 59 - Fixing pylint errors In-Reply-To: <1370384181.11363.2.camel@akoneru.redhat.com> References: <1370384181.11363.2.camel@akoneru.redhat.com> Message-ID: <51AFF717.4030509@redhat.com> On 6/4/2013 5:16 PM, Abhishek Koneru wrote: > Please review the patch which fixes issues related to application of PEP > 8 standards to the python code, raised in pylint scan. > > Should be applied over patch 59, which is also attached here. > > --Abhishek The changes look fine, but most likely it will need a rebase. ACK. -- Endi S. Dewata From alee at redhat.com Thu Jun 6 04:14:05 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 06 Jun 2013 00:14:05 -0400 Subject: [Pki-devel] [PATCH] Updated man pages In-Reply-To: <51AFE62B.9030403@redhat.com> References: <51AFE62B.9030403@redhat.com> Message-ID: <1370492045.27708.0.camel@aleeredhat.laptop> ACK On Wed, 2013-06-05 at 18:30 -0700, Matthew Harmsen wrote: > Please review the attached patch for Dogtag 10.0.3 which resolves the > following TRAC tickets: > * TRAC Ticket #606 - add restart / start at boot info to > pkispawn man page > * TRAC Ticket #610 - Document limitation in using GUI install > * TRAC Ticket #629 - Package ownership of '/usr/share/pki/etc/' > directory > The changes for Dogtag 10.1 are identical. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Jun 6 04:24:13 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 06 Jun 2013 00:24:13 -0400 Subject: [Pki-devel] [PATCH] 61 Change how installation summary is displayed. Ticket#599 - Dogtag 10.0.3 In-Reply-To: <1370457521.8342.3.camel@akoneru.redhat.com> References: <1370457521.8342.3.camel@akoneru.redhat.com> Message-ID: <1370492653.27708.5.camel@aleeredhat.laptop> Looks pretty good, but still can easily overflow on an 80 char window. Lets do something like this - that is, break up some of the lines. ========================================================================== INSTALLATION SUMMARY ========================================================================== Admin username: caadmin Client certificate nickname: PKI Administrator for laptop To check the status of the subsystem: systemctl status pki-tomcatd\@pki-tomcat34.service To restart the subsystem: systemctl restart pki-tomcatd\@pki-tomcat34.service The URL for the subsystem is https://aleeredhat.laptop:8343/ca ========================================================================== - Ade On Wed, 2013-06-05 at 14:38 -0400, Abhishek Koneru wrote: > Please review the patch which shows the installation summary, only when > pki_skip_configuration is not True. Also the client database details are > shown only when pki_client_database_purge=False. > > The configuration url is already shown when pki_skip_configuration = > true. > > --Abhishek > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Jun 6 04:27:41 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 05 Jun 2013 23:27:41 -0500 Subject: [Pki-devel] [PATCH] 61 Change how installation summary is displayed. Ticket#599 - Dogtag 10.0.3 In-Reply-To: <1370457521.8342.3.camel@akoneru.redhat.com> References: <1370457521.8342.3.camel@akoneru.redhat.com> Message-ID: <51B00FBD.3060407@redhat.com> On 6/5/2013 1:38 PM, Abhishek Koneru wrote: > Please review the patch which shows the installation summary, only when > pki_skip_configuration is not True. Also the client database details are > shown only when pki_client_database_purge=False. > > The configuration url is already shown when pki_skip_configuration = > true. > > --Abhishek ACK, but there are a few things that can be done separately: 1. In ticket #599, item #3 says that the configuration URL should be displayed in the installation summary if we're skipping configuration. In other words, pkispawn should always end with an installation summary. Probably something like this: ========================================================================== INSTALLATION SUMMARY ========================================================================== Please start the configuration by accessing: https://test.example.com:8443/ca/admin/console/config/login?pin=DX5SF6JLfhdntJoQGp3X After configuration, the server can be operated by the command: systemctl restart pki-tomcatd at ca-master.service ========================================================================== 2. Since we have installation summary, the "Installation complete" message might not be needed anymore. -- Endi S. Dewata From alee at redhat.com Thu Jun 6 15:34:12 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 06 Jun 2013 11:34:12 -0400 Subject: [Pki-devel] [PATCH] Updated man pages In-Reply-To: <1370492045.27708.0.camel@aleeredhat.laptop> References: <51AFE62B.9030403@redhat.com> <1370492045.27708.0.camel@aleeredhat.laptop> Message-ID: <1370532852.2234.1.camel@localhost.localdomain> Pushed to dogtag 10.0 branch. Please push to master with appropriate changes to spec files. On Thu, 2013-06-06 at 00:14 -0400, Ade Lee wrote: > ACK > > On Wed, 2013-06-05 at 18:30 -0700, Matthew Harmsen wrote: > > Please review the attached patch for Dogtag 10.0.3 which resolves the > > following TRAC tickets: > > * TRAC Ticket #606 - add restart / start at boot info to > > pkispawn man page > > * TRAC Ticket #610 - Document limitation in using GUI install > > * TRAC Ticket #629 - Package ownership of '/usr/share/pki/etc/' > > directory > > The changes for Dogtag 10.1 are identical. > > _______________________________________________ > > 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 akoneru at redhat.com Thu Jun 6 15:39:15 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 06 Jun 2013 11:39:15 -0400 Subject: [Pki-devel] [PATCH] 58-2 Minor fixes for patch 58 In-Reply-To: <51AFDB66.8080806@redhat.com> References: <1369155772.8356.2.camel@akoneru.redhat.com> <519FA9C6.8060104@redhat.com> <1370028041.4953.2.camel@akoneru.redhat.com> <51AFDB66.8080806@redhat.com> Message-ID: <1370533155.12576.3.camel@akoneru.redhat.com> Fixed and pushed to master. --Abhsihek On Wed, 2013-06-05 at 19:44 -0500, Endi Sukma Dewata wrote: > On 5/31/2013 2:20 PM, Abhishek Koneru wrote: > >> 1. In drmclient.py, in http_request() and https_request() suppose the > >> NSSConnection supports Context Manager we could use 'with' statement > >> too. Could you check? > >> > >> http://docs.python.org/2/reference/compound_stmts.html#with > >> > >> 2. Also in http_request() and https_request(), I'm not sure if we really > >> need to wrap the original exception, but that's a separate issue. If we > >> can remove it we can use 'with' here, or at least nest it. > > > > Both NSSConnection and httplib.HTTPConnection do not support Context > > Manager. Hence, no changes made here. > > OK. > > >> 3. In kra.__init__() the self.password = '' assignment can be moved > >> before open() so in case of error it will be blank already. This way we > >> can use the 'with' statement. > > -- Nested the with in the try-except block > > There's a trailing space on line 419. Please fix before push. > > >> 4. In pkimanifest.py, in file.write() and read() the error logging > >> should really be done by the caller. But here at least we can use 'with' > >> nested inside the 'try-except'. > > used with for file operations > >> > > Please review the attached patch. > > ACK. > From edewata at redhat.com Thu Jun 6 18:51:33 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Jun 2013 13:51:33 -0500 Subject: [Pki-devel] Need python-backports-ssl_match_hostname-3.2-0.2 for RHEL 7.0 Message-ID: <51B0DA35.2080507@redhat.com> Hi, Please add python-backports-ssl_match_hostname-3.2-0.2 package into RHEL 7.0. Currently the package exists in Fedora 19, but not in RHEL 7.0. If there is nobody else, please assign me as the maintainer: edewata The package is eventually needed by pki-ca package (Bugzilla #966040): https://bugzilla.redhat.com/show_bug.cgi?id=966040 Thanks. -- Endi S. Dewata From alee at redhat.com Fri Jun 7 16:05:27 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 07 Jun 2013 12:05:27 -0400 Subject: [Pki-devel] Announcing the release of Dogtag 10.0.3 Message-ID: <1370621127.5909.1.camel@aleeredhat.laptop> The Dogtag team is proud to announce the third errata build for Dogtag v10.0.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. == Build Versions == pki-core-10.0.3-1 pki-ra-10.0.3-1 pki-tps-10.0.3-1 dogtag-pki-10.0.3-1 dogtag-pki-theme-10.0.3-1 pki-console-10.0.3-1 == Highlights since Dogtag v. 10.0.2 == * Fixes for security flaws in the TPS as described in CVE-2013-1885 and CVE-2013-1886 * Added checking for sane lengths of the fields in subject DNs in the TPS, to prevent a TPS crash. * Previously the server certificate name was partially hard-coded. Now in Tomcat-based subsystems, it can be fully configured using pki_ssl_server_nickname parameter. * Corrections and additions to man pages and other documentation. == Detailed Changes since Dogtag v. 10.0.2 == akoneru (1): #599 Improve pkispawn "Installation Summary" block alee (1): #486 Document migration steps for dogtag 9 -> dogtag 10 instances awnuk (4): #607 Port plug-in randomizing validity #571 Port patch allowing to include in CRLs NextUpdate calculated base on ThisUpdate BZ 951501 - correcting JavaScript inability to handle big numbers BZ 966189 - fix various TPS flaws cfu (1): BZ 952500 - small patch to remove eclipse warning in fix to BZ 952500 edewata (1) #631 Hard-coded server certificate nickname. jmagne (1): BZ 963073 - rhcs81 tps crash for CN over than 64 bytes mharmsen (3): #606 add restart/start at boot info to pkispawn man page #610 Document limitation in using GUI install #629 Package ownership of '/usr/share/pki/etc/' directory From edewata at redhat.com Mon Jun 10 17:50:20 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Jun 2013 12:50:20 -0500 Subject: [Pki-devel] [PATCH] 262 Added Tomcat-based TPS instance. In-Reply-To: <665441867.14325964.1370386539766.JavaMail.root@redhat.com> References: <51A79907.3070807@redhat.com> <51A7C9BD.1000302@redhat.com> <665441867.14325964.1370386539766.JavaMail.root@redhat.com> Message-ID: <51B611DC.7020600@redhat.com> On 6/4/2013 5:55 PM, John Magne wrote: > ACK > > Just went through the list of stuff quickly. > Appears to be a fine template of files for a new Java TPS instance. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Jun 10 17:55:01 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 10 Jun 2013 12:55:01 -0500 Subject: [Pki-devel] [PATCH] 263 Added TPS servlet. In-Reply-To: <227904603.14326184.1370386606486.JavaMail.root@redhat.com> References: <51A79928.8080609@redhat.com> <227904603.14326184.1370386606486.JavaMail.root@redhat.com> Message-ID: <51B612F5.5040305@redhat.com> On 6/4/2013 5:56 PM, John Magne wrote: > ACK > > Looks good. Just for fun you might want to add a bit to the demo so that it returns an > error APDU back to the client at the end to see if the client can process it. Pushed to master. Thanks. I'm planning to convert this demo servlet into unit tests, which include the error APDU as well. -- Endi S. Dewata From alee at redhat.com Tue Jun 11 04:05:59 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 11 Jun 2013 00:05:59 -0400 Subject: [Pki-devel] [PATCH] 133 - fix java tools invocation scripts on f19 Message-ID: <1370923559.2400.2.camel@aleeredhat.laptop> Modify java-tools startup scripts to use correct JNI path In Fedora 19, the JNI path changed yet again, breaking all java-tools because the classpath does not contain the correct location for jss4.jar on x86_64. With this fix, both /usr/lib/java/jss4.jar and /usr/lib64/java/jss4.jar are in the classpath. Trac Ticket 646 Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0133-Modify-java-tools-startup-scripts-to-use-correct-JNI.patch Type: text/x-patch Size: 3686 bytes Desc: not available URL: From mharmsen at redhat.com Tue Jun 11 18:21:38 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 11 Jun 2013 11:21:38 -0700 Subject: [Pki-devel] [PATCH] 133 - fix java tools invocation scripts on f19 In-Reply-To: <1370923559.2400.2.camel@aleeredhat.laptop> References: <1370923559.2400.2.camel@aleeredhat.laptop> Message-ID: <51B76AB2.4090905@redhat.com> On 06/10/13 21:05, Ade Lee wrote: > Modify java-tools startup scripts to use correct JNI path > > In Fedora 19, the JNI path changed yet again, breaking all java-tools > because the classpath does not contain the correct location for jss4.jar > on x86_64. With this fix, both /usr/lib/java/jss4.jar and > /usr/lib64/java/jss4.jar are in the classpath. > > Trac Ticket 646 > > Please review. > > Thanks, > 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 edewata at redhat.com Tue Jun 11 19:29:19 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 11 Jun 2013 14:29:19 -0500 Subject: [Pki-devel] [PATCH] 265 Fixed library paths for RHEL 7. Message-ID: <51B77A8F.6090003@redhat.com> The build files have been modified to use the correct library paths on RHEL 7: - libldap.so and liblber.so are in /usr/lib64 - jss4.jar is in /usr/lib - Tomcat JSS filename is tomcatjss.jar -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0265-Fixed-library-paths-for-RHEL-7.patch Type: text/x-patch Size: 2336 bytes Desc: not available URL: From alee at redhat.com Tue Jun 11 20:59:45 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 11 Jun 2013 16:59:45 -0400 Subject: [Pki-devel] [PATCH] 133 - fix java tools invocation scripts on f19 In-Reply-To: <51B76AB2.4090905@redhat.com> References: <1370923559.2400.2.camel@aleeredhat.laptop> <51B76AB2.4090905@redhat.com> Message-ID: <1370984385.8991.11.camel@aleeredhat.laptop> rewritten to use pki.conf. please review. Ade On Tue, 2013-06-11 at 11:21 -0700, Matthew Harmsen wrote: > On 06/10/13 21:05, Ade Lee wrote: > > > Modify java-tools startup scripts to use correct JNI path > > > > In Fedora 19, the JNI path changed yet again, breaking all java-tools > > because the classpath does not contain the correct location for jss4.jar > > on x86_64. With this fix, both /usr/lib/java/jss4.jar and > > /usr/lib64/java/jss4.jar are in the classpath. > > > > Trac Ticket 646 > > > > Please review. > > > > Thanks, > > Ade > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > ACK > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0133-1-Modify-java-tools-startup-scripts-to-use-correct-JNI.patch Type: text/x-patch Size: 4640 bytes Desc: not available URL: From alee at redhat.com Tue Jun 11 21:01:57 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 11 Jun 2013 17:01:57 -0400 Subject: [Pki-devel] [PATCH] 265 Fixed library paths for RHEL 7. In-Reply-To: <51B77A8F.6090003@redhat.com> References: <51B77A8F.6090003@redhat.com> Message-ID: <1370984517.8991.12.camel@aleeredhat.laptop> ack On Tue, 2013-06-11 at 14:29 -0500, Endi Sukma Dewata wrote: > The build files have been modified to use the correct library paths > on RHEL 7: > - libldap.so and liblber.so are in /usr/lib64 > - jss4.jar is in /usr/lib > - Tomcat JSS filename is tomcatjss.jar > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Jun 11 23:29:48 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 11 Jun 2013 18:29:48 -0500 Subject: [Pki-devel] [PATCH] 265 Fixed library paths for RHEL 7. In-Reply-To: <1370984517.8991.12.camel@aleeredhat.laptop> References: <51B77A8F.6090003@redhat.com> <1370984517.8991.12.camel@aleeredhat.laptop> Message-ID: <51B7B2EC.9050004@redhat.com> On 6/11/2013 4:01 PM, Ade Lee wrote: > ack Pushed to master and 10.0 branch. -- Endi S. Dewata From edewata at redhat.com Tue Jun 11 23:29:52 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 11 Jun 2013 18:29:52 -0500 Subject: [Pki-devel] [PATCH] 133 - fix java tools invocation scripts on f19 In-Reply-To: <1370984385.8991.11.camel@aleeredhat.laptop> References: <1370923559.2400.2.camel@aleeredhat.laptop> <51B76AB2.4090905@redhat.com> <1370984385.8991.11.camel@aleeredhat.laptop> Message-ID: <51B7B2F0.7000905@redhat.com> On 6/11/2013 3:59 PM, Ade Lee wrote: > rewritten to use pki.conf. > > please review. > Ade ACK. There are actually a few more locations, but they may not actually cause problems so they can be fixed separately later. 1. In base/common/shared/conf/pki.policy the 2 possible jss4.jar paths are hardcoded. We should be able to pass the JNI_JAR_DIR just like the RESTEASY_LIB. 2. In base/console/templates/pki_console_wrapper the paths are stacked, so it should still work assuming there's only one JSS version installed. 3. In base/java-tools/pki the paths are stacked. 4. In base/setup/scripts/functions the jni_dir is hardcoded, but this seems to be only used by Dogtag 9. 5. In base/silent/scripts/pkisilent the paths are stacked. 6. In scripts/dev_setup the ARCH might not be correct for F19, but this is only used to initialize dev environment. -- Endi S. Dewata From edewata at redhat.com Wed Jun 12 04:26:18 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 11 Jun 2013 23:26:18 -0500 Subject: [Pki-devel] [PATCH] 266 Fixed RA and TPS dependencies on other PKI packages. Message-ID: <51B7F86A.3030305@redhat.com> The RA and TPS spec files have been modified to depend on pki-server, pki-server-theme, and pki-symkey version 10.1.0 or later. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0266-Fixed-RA-and-TPS-dependencies-on-other-PKI-packages.patch Type: text/x-patch Size: 3140 bytes Desc: not available URL: From alee at redhat.com Wed Jun 12 14:52:08 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 12 Jun 2013 10:52:08 -0400 Subject: [Pki-devel] [PATCH] 133 - fix java tools invocation scripts on f19 In-Reply-To: <51B7B2F0.7000905@redhat.com> References: <1370923559.2400.2.camel@aleeredhat.laptop> <51B76AB2.4090905@redhat.com> <1370984385.8991.11.camel@aleeredhat.laptop> <51B7B2F0.7000905@redhat.com> Message-ID: <1371048728.8991.46.camel@aleeredhat.laptop> On Tue, 2013-06-11 at 18:29 -0500, Endi Sukma Dewata wrote: > On 6/11/2013 3:59 PM, Ade Lee wrote: > > rewritten to use pki.conf. > > > > please review. > > Ade > > ACK. > > There are actually a few more locations, but they may not actually cause > problems so they can be fixed separately later. > > 1. In base/common/shared/conf/pki.policy the 2 possible jss4.jar paths > are hardcoded. We should be able to pass the JNI_JAR_DIR just like the > RESTEASY_LIB. > > 2. In base/console/templates/pki_console_wrapper the paths are stacked, > so it should still work assuming there's only one JSS version installed. > > 3. In base/java-tools/pki the paths are stacked. > > 4. In base/setup/scripts/functions the jni_dir is hardcoded, but this > seems to be only used by Dogtag 9. > > 5. In base/silent/scripts/pkisilent the paths are stacked. > > 6. In scripts/dev_setup the ARCH might not be correct for F19, but this > is only used to initialize dev environment. > Yeah, I specifically decided beforehand not to fix these are they were causing no problems. They can be fixed in a separate ticket. Pushed to Dogtag 10.0 branch and master From edewata at redhat.com Wed Jun 12 16:42:11 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 12 Jun 2013 11:42:11 -0500 Subject: [Pki-devel] [PATCH] 266 Fixed RA and TPS dependencies on other PKI packages. In-Reply-To: <51B7F86A.3030305@redhat.com> References: <51B7F86A.3030305@redhat.com> Message-ID: <51B8A4E3.8000201@redhat.com> On 6/11/2013 11:26 PM, Endi Sukma Dewata wrote: > The RA and TPS spec files have been modified to depend on pki-server, > pki-server-theme, and pki-symkey version 10.1.0 or later. ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Jun 13 21:41:14 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 13 Jun 2013 16:41:14 -0500 Subject: [Pki-devel] [PATCH] 267-268 Updated tomcatjss for Fedora 18 & 19. Message-ID: <51BA3C7A.4000606@redhat.com> Attached are Matt's patches for tomcatjss that have been ported to Fedora 18 & 19. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0267-Updated-tomcatjss-for-Fedora-18.patch Type: text/x-patch Size: 2670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0268-Updated-tomcatjss-for-Fedora-19.patch Type: text/x-patch Size: 3277 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 14 17:29:52 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Jun 2013 12:29:52 -0500 Subject: [Pki-devel] [PATCH] 267-268 Updated tomcatjss for Fedora 18 & 19. In-Reply-To: <51BA3C7A.4000606@redhat.com> References: <51BA3C7A.4000606@redhat.com> Message-ID: <51BB5310.5010602@redhat.com> On 6/13/2013 4:41 PM, Endi Sukma Dewata wrote: > Attached are Matt's patches for tomcatjss that have been ported to > Fedora 18 & 19. Patch #267 was revised to change the merged spec instead of the tomcat7jss spec. Both were ACKed by Ade. Pushed to the corresponding branches. -- Endi S. Dewata From alee at redhat.com Fri Jun 14 18:01:15 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 14 Jun 2013 14:01:15 -0400 Subject: [Pki-devel] New builds in bodhi Message-ID: <1371232875.2788.3.camel@aleeredhat.laptop> Hi all, New builds have been posted to bodhi for pki-core-10.0.3-2 (F18 and F19) and tomcatjss (7.0.0-5 F18) and (7.1.0-3 F19). Please test and provide karma. F19 testing is particularly important because the change deadline is Tuesday. Ade From edewata at redhat.com Sat Jun 15 02:29:23 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 14 Jun 2013 21:29:23 -0500 Subject: [Pki-devel] [PATCH] 269 Updated Java dependencies to version 1.7. Message-ID: <51BBD183.2010202@redhat.com> The spec files have been updated to require Java 1.7 for build and runtime. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0269-Updated-Java-dependencies-to-version-1.7.patch Type: text/x-patch Size: 9457 bytes Desc: not available URL: From alee at redhat.com Mon Jun 17 15:07:52 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 17 Jun 2013 11:07:52 -0400 Subject: [Pki-devel] [PATCH] 269 Updated Java dependencies to version 1.7. In-Reply-To: <51BBD183.2010202@redhat.com> References: <51BBD183.2010202@redhat.com> Message-ID: <1371481672.2641.1.camel@aleeredhat.laptop> ack On Fri, 2013-06-14 at 21:29 -0500, Endi Sukma Dewata wrote: > The spec files have been updated to require Java 1.7 for build > and runtime. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Mon Jun 17 15:48:07 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 17 Jun 2013 10:48:07 -0500 Subject: [Pki-devel] [PATCH] 269 Updated Java dependencies to version 1.7. In-Reply-To: <1371481672.2641.1.camel@aleeredhat.laptop> References: <51BBD183.2010202@redhat.com> <1371481672.2641.1.camel@aleeredhat.laptop> Message-ID: <51BF2FB7.1070707@redhat.com> On 6/17/2013 10:07 AM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From akoneru at redhat.com Mon Jun 24 21:29:12 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Mon, 24 Jun 2013 17:29:12 -0400 Subject: [Pki-devel] [PATCH] 59-2 Fixing for comments given for Patch 59 In-Reply-To: <51AFF637.8000807@redhat.com> References: <1370032689.4953.7.camel@akoneru.redhat.com> <51AFF637.8000807@redhat.com> Message-ID: <1372109352.23453.28.camel@akoneru.redhat.com> Please review the patch with the changes suggested by Endi to refactor code inorder to maintain references to the global variables and the utility classes. A new class PKIDeployer is added to pkihelper.py, whose object is created in pkispawn/pkidestroy to hold the references and be passed to the PKIScriptlets. Declarations for pki_master_dict and pki_slots_dict have been moved to init method in pkiparser.py from pkiconfig. The compose methods are called in pkispawn/pkidestroy and then the references passed to the PKIDeployer object. This also fixes many issues of tpe E1120 reported by pylint. --Abhishek On Wed, 2013-06-05 at 21:38 -0500, Endi Sukma Dewata wrote: > On 5/31/2013 3:38 PM, Abhishek Koneru wrote: > > Please review the patch which fixes a few errors reported by pylint in > > dogtag's python code. > > > > Also find attached the remaining errors to be fixed. Will submit a > > detailed report in my next mail. > > > > How i used pylint: > > > > -- Installed pki packages. > > -- Executed the following command - > > cd /usr/lib/python2.7/sitepackages; pylint -E --include-ids=y pki/ > > pki/deployment/ pki/server/ `which pkispawn` `which pkidestroy` `which > > pki-upgrade` `which pki-server-upgrade` > > > > --Abhishek > > Looking at the pkihelper.py again, I'm not sure if this is the right > approach. In the original code the classes are instantiated into global > objects and we're calling the methods of these objects like this: > > uid = identity.get_uid() > > In the new code the methods are converted into static methods: > > uid = Identity.get_uid() > > The problem is many of these methods actually depend on other global > objects such as 'master', so we haven't really removed the dependency on > global variables. > > I'm thinking we probably should encapsulate the global objects into an > object that we can pass around, then we access them as local variables. > For example, in pkispawn we generate the master object and put it in a > Deployer object. Then we pass the deployer object to the scriptlets. > > deployer = pki.server.Deployer(master) > > instance = scriptlet.PkiScriptlet() > instance.spawn(deployer) > > The Deployer class will have methods that generate the old global > objects and we pass the master into those objects: > > def get_identity(self): > return Identity(master) > > In the scriptlets we can call the methods this way: > > identity = deployer.get_identity() > uid = identity.get_uid() > > What do you think? > > If we do this, I'd suggest we do the conversion one global object at a > time so it's easier to review. > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0059-2-Code-refactored-for-global-variables-and-utility-cla.patch Type: text/x-patch Size: 292471 bytes Desc: not available URL: From jmagne at redhat.com Tue Jun 25 02:12:49 2013 From: jmagne at redhat.com (John Magne) Date: Mon, 24 Jun 2013 22:12:49 -0400 (EDT) Subject: [Pki-devel] UPDATE Bug 976788 - pki-ca 9.0.26 adds new required option, -client_token_name In-Reply-To: <82866911.26555200.1372125981059.JavaMail.root@redhat.com> Message-ID: <1368131836.26558590.1372126369470.JavaMail.root@redhat.com> I believe I have the code locally to prevent the IPA install from failing due to missing arguments. Unfortunately, my test IPA install is failing on my VM when pkisilent tries to connect to the ca's wizard. It appears that the installed CA is not restarting properly after pkicreate is called. If this is a known glitch, I'd glad to hear any tips on how to avoid it, and then I can finish this test. From jmagne at redhat.com Tue Jun 25 17:40:29 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 25 Jun 2013 13:40:29 -0400 (EDT) Subject: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch In-Reply-To: <1663074363.27408484.1372181971708.JavaMail.root@redhat.com> Message-ID: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> Attached patch should resolve 976788. The identified pkisilent paramaters are no longer treated as required and should allow the IPA install to finish properly. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Bug-976788.patch Type: text/x-patch Size: 14228 bytes Desc: not available URL: From edewata at redhat.com Tue Jun 25 18:15:56 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Jun 2013 13:15:56 -0500 Subject: [Pki-devel] TPS REST interface design Message-ID: <51C9DE5C.1@redhat.com> Hi, This is the initial draft of the TPS REST interface design: http://pki.fedoraproject.org/wiki/TPS_REST_Interface Please take a look and let me know if you have any comments. Thanks! -- Endi S. Dewata From alee at redhat.com Tue Jun 25 18:36:45 2013 From: alee at redhat.com (Ade Lee) Date: Tue, 25 Jun 2013 14:36:45 -0400 Subject: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch In-Reply-To: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> References: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> Message-ID: <1372185405.18697.1.camel@aleeredhat.laptop> Conditional ACK. 1. We should not be providing default passwords for the pk12 file. Please revert that change and retest. 2. The spec file changelog needs its own stanza. Pending testing with installing IPA with those changes, ACK. Ade On Tue, 2013-06-25 at 13:40 -0400, John Magne wrote: > Attached patch should resolve 976788. > The identified pkisilent paramaters are no longer treated as required and should allow the IPA install to finish properly. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Tue Jun 25 21:26:52 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 25 Jun 2013 17:26:52 -0400 (EDT) Subject: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch In-Reply-To: <1372185405.18697.1.camel@aleeredhat.laptop> References: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> <1372185405.18697.1.camel@aleeredhat.laptop> Message-ID: <1948607274.27702124.1372195612955.JavaMail.root@redhat.com> Pushed to master based on conditional ACK, after suggested changes and testing performed. ----- Original Message ----- > From: "Ade Lee" > To: "John Magne" > Cc: "pki-devel" > Sent: Tuesday, June 25, 2013 11:36:45 AM > Subject: Re: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch > > Conditional ACK. > > 1. We should not be providing default passwords for the pk12 file. > Please revert that change and retest. > > 2. The spec file changelog needs its own stanza. > > Pending testing with installing IPA with those changes, ACK. > > Ade > On Tue, 2013-06-25 at 13:40 -0400, John Magne wrote: > > Attached patch should resolve 976788. > > The identified pkisilent paramaters are no longer treated as required and > > should allow the IPA install to finish properly. > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > From jmagne at redhat.com Tue Jun 25 21:27:39 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 25 Jun 2013 17:27:39 -0400 (EDT) Subject: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch In-Reply-To: <1948607274.27702124.1372195612955.JavaMail.root@redhat.com> References: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> <1372185405.18697.1.camel@aleeredhat.laptop> <1948607274.27702124.1372195612955.JavaMail.root@redhat.com> Message-ID: <1525525912.27702737.1372195659931.JavaMail.root@redhat.com> Correction: Pushed to origin/DOGTAG_9_BRANCH . ----- Original Message ----- > From: "John Magne" > To: alee at redhat.com > Cc: "pki-devel" > Sent: Tuesday, June 25, 2013 2:26:52 PM > Subject: Re: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch > > > Pushed to master based on conditional ACK, after suggested changes and > testing performed. > > > > ----- Original Message ----- > > From: "Ade Lee" > > To: "John Magne" > > Cc: "pki-devel" > > Sent: Tuesday, June 25, 2013 11:36:45 AM > > Subject: Re: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch > > > > Conditional ACK. > > > > 1. We should not be providing default passwords for the pk12 file. > > Please revert that change and retest. > > > > 2. The spec file changelog needs its own stanza. > > > > Pending testing with installing IPA with those changes, ACK. > > > > Ade > > On Tue, 2013-06-25 at 13:40 -0400, John Magne wrote: > > > Attached patch should resolve 976788. > > > The identified pkisilent paramaters are no longer treated as required and > > > should allow the IPA install to finish properly. > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From cfu at redhat.com Tue Jun 25 22:16:37 2013 From: cfu at redhat.com (Christina Fu) Date: Tue, 25 Jun 2013 15:16:37 -0700 Subject: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch In-Reply-To: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> References: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> Message-ID: <51CA16C5.3000402@redhat.com> How about those templates? I didn't see any template changes in the patch. Are they on their way? thanks, Christina On 06/25/2013 10:40 AM, John Magne wrote: > Attached patch should resolve 976788. > The identified pkisilent paramaters are no longer treated as required and should allow the IPA install to finish properly. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Tue Jun 25 22:23:07 2013 From: jmagne at redhat.com (John Magne) Date: Tue, 25 Jun 2013 18:23:07 -0400 (EDT) Subject: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch In-Reply-To: <51CA16C5.3000402@redhat.com> References: <388047693.27408706.1372182029062.JavaMail.root@redhat.com> <51CA16C5.3000402@redhat.com> Message-ID: <103324590.27756387.1372198987812.JavaMail.root@redhat.com> What template changes? I fixed the problem. The params are no longer required. ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, June 25, 2013 3:16:37 PM Subject: Re: [Pki-devel] [PATCH] [001] 0001-Bug-976788.patch How about those templates? I didn't see any template changes in the patch. Are they on their way? thanks, Christina On 06/25/2013 10:40 AM, John Magne wrote: > Attached patch should resolve 976788. > The identified pkisilent paramaters are no longer treated as required and should allow the IPA install to finish properly. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Jun 25 23:40:04 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 25 Jun 2013 18:40:04 -0500 Subject: [Pki-devel] [PATCH] 59-2 Fixing for comments given for Patch 59 In-Reply-To: <1372109352.23453.28.camel@akoneru.redhat.com> References: <1370032689.4953.7.camel@akoneru.redhat.com> <51AFF637.8000807@redhat.com> <1372109352.23453.28.camel@akoneru.redhat.com> Message-ID: <51CA2A54.8060200@redhat.com> On 6/24/2013 4:29 PM, Abhishek Koneru wrote: > Please review the patch with the changes suggested by Endi to refactor > code inorder to maintain references to the global variables and the > utility classes. > > A new class PKIDeployer is added to pkihelper.py, whose object is > created in pkispawn/pkidestroy to hold the references and be passed to > the PKIScriptlets. > > Declarations for pki_master_dict and pki_slots_dict have been moved to > init method in pkiparser.py from pkiconfig. The compose methods are > called in pkispawn/pkidestroy and then the references passed to the > PKIDeployer object. > > This also fixes many issues of tpe E1120 reported by pylint. > > --Abhishek Some comments: 1. The helper class names begin with underscore (e.g. _Identity). I don't think this is necessary. These classes will be used by scriptlet writers, so they aren't meant to be private classes. 2. Some of the constructors are defined like this: def __init__(self, pki_master_dict, identity = None): self.master_dict = pki_master_dict if identity is None: self.identity = _Identity(pki_master_dict) else: self.identity = identity Since these classes are always used with the deployer object, we can simplify it like this: def __init__(self, deployer): self.master_dict = deployer.pki_master_dict self.identity = deployer.identity Using the deployer guarantees that the dicts and helper objects are already created, so there's no need to create the objects again. 3. There are some trailing whitespaces. Everything else is fine, the code works. With the above issues fixed, ACK. As future enhancement, it's possible to simplify the scriptlets further. For example: deployer.file.copy_with_slot_substitution( deployer.master_dict['pki_source_catalina_properties'], deployer.master_dict['pki_target_catalina_properties'], overwrite_flag=True) If the method is always used with values from the master_dict, the above line can be simplified as follows: deployer.file.copy_with_slot_substitution( 'pki_source_catalina_properties', 'pki_target_catalina_properties', overwrite_flag=True) -- Endi S. Dewata From alee at redhat.com Wed Jun 26 18:16:03 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 14:16:03 -0400 Subject: [Pki-devel] [PATCH] 8.1 - fix cloning issues BZ 97145 Message-ID: <1372270563.2154.4.camel@aleeredhat.laptop> This patch fixes the problems described in https://bugzilla.redhat.com/show_bug.cgi?id=976145 Basically, there are some errors in the logic for parsing the security domain for cloning installs where the master is running pre-IP separation software. Also, included is a fix for https://bugzilla.redhat.com/show_bug.cgi?id=956796 Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: fix1.patch Type: text/x-patch Size: 6875 bytes Desc: not available URL: From alee at redhat.com Wed Jun 26 18:28:42 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 14:28:42 -0400 Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported Message-ID: <1372271322.2154.6.camel@aleeredhat.laptop> Make sure only the master keys and certs are imported. The key import code was written for when there was only one subsystem per tomcat instance, and only one subsystems certs and keys per p12 file. We need to ensure that only the master's subsystem keys and certs are imported. Otherwise, unpredictable behavior happens, like in Ticket 665. Please review, Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0134-Make-sure-only-the-master-keys-and-certs-are-importe.patch Type: text/x-patch Size: 3211 bytes Desc: not available URL: From alee at redhat.com Wed Jun 26 20:56:52 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 16:56:52 -0400 Subject: [Pki-devel] [PATCH] 135 - handle case where no subsystem certs are created Message-ID: <1372280212.31409.1.camel@aleeredhat.laptop> Modify pkispawn to handle case where no subsystemCerts are generated When installing clone of a KRA into an existing instance, no new system certs are generated, and so the systemCerts parameter is not populated. This patch addresses this issue. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0135-Modify-pkispawn-to-handle-case-where-no-subsystemCer.patch Type: text/x-patch Size: 1374 bytes Desc: not available URL: From jmagne at redhat.com Wed Jun 26 23:03:52 2013 From: jmagne at redhat.com (John Magne) Date: Wed, 26 Jun 2013 19:03:52 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported In-Reply-To: <1372271322.2154.6.camel@aleeredhat.laptop> References: <1372271322.2154.6.camel@aleeredhat.laptop> Message-ID: <436487515.28863007.1372287832393.JavaMail.root@redhat.com> Ade: This looks good but I have a question. Looking at the function you added: private static boolean importRequired(ArrayList masterList, String nickname) { + if (masterList.contains(nickname)) + return true; + try { + X500Name xname = new X500Name(nickname); + for (String key: masterList) { + try { + X500Name xkey = new X500Name(key); + if (xkey.equals(xname)) return true; + } catch (IOException e) { + // xkey not an X500Name + } + } + + } catch (IOException e) { + // nickname is not a x500Name + return false; + } + return false; + } It looks like the top of this function does a String comparison just like the code you had in there but commented out already: if (masterList.contains(nickname)) + return true; As I understand the List contains method calls the equals method of the objects involved. Subsequently it looks like you rifle through the whole list and do a comparison between X500Name objects, which represent distinguished names. Why is this done? There are cases where the DN's are equivalent but their raw Strings may differ? thanks, jack ----- Original Message ----- > From: "Ade Lee" > To: pki-devel at redhat.com > Sent: Wednesday, June 26, 2013 11:28:42 AM > Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported > > Make sure only the master keys and certs are imported. > > The key import code was written for when there was only one > subsystem per tomcat instance, and only one subsystems certs > and keys per p12 file. We need to ensure that only the master's > subsystem keys and certs are imported. Otherwise, unpredictable > behavior happens, like in Ticket 665. > > Please review, > > Thanks, > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Wed Jun 26 23:15:54 2013 From: jmagne at redhat.com (John Magne) Date: Wed, 26 Jun 2013 19:15:54 -0400 (EDT) Subject: [Pki-devel] [PATCH] 135 - handle case where no subsystem certs are created In-Reply-To: <1372280212.31409.1.camel@aleeredhat.laptop> References: <1372280212.31409.1.camel@aleeredhat.laptop> Message-ID: <450452743.28865199.1372288554113.JavaMail.root@redhat.com> Looks good. ACK. Question though. Would it make any sense to log this exception. I suppose that is what the following construct is for: except KeyError as exc: thanks, jack ----- Original Message ----- From: "Ade Lee" To: pki-devel at redhat.com Sent: Wednesday, June 26, 2013 1:56:52 PM Subject: [Pki-devel] [PATCH] 135 - handle case where no subsystem certs are created Modify pkispawn to handle case where no subsystemCerts are generated When installing clone of a KRA into an existing instance, no new system certs are generated, and so the systemCerts parameter is not populated. This patch addresses this issue. Please review. Ade _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Wed Jun 26 23:36:39 2013 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 26 Jun 2013 16:36:39 -0700 Subject: [Pki-devel] [PATCH] 8.1 - fix cloning issues BZ 97145 In-Reply-To: <1372270563.2154.4.camel@aleeredhat.laptop> References: <1372270563.2154.4.camel@aleeredhat.laptop> Message-ID: <51CB7B07.9050907@redhat.com> On 06/26/13 11:16, Ade Lee wrote: > This patch fixes the problems described in > https://bugzilla.redhat.com/show_bug.cgi?id=976145 > > Basically, there are some errors in the logic for parsing the security > domain for cloning installs where the master is running pre-IP > separation software. > > Also, included is a fix for > https://bugzilla.redhat.com/show_bug.cgi?id=956796 > > Please review. > Thanks, > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK Apply these fixes to: * PKI_8_1_ERRATA_BRANCH (8.1.1), and * PKI_8_BRANCH (8.2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Thu Jun 27 00:14:41 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 26 Jun 2013 17:14:41 -0700 Subject: [Pki-devel] New Dogtag 9 packages Message-ID: <51CB83F1.9010104@redhat.com> Hi, New Dogtag 9 packages are available in Koji for Fedora 17: * pki-core-9.0.27-1.fc17 * dogtag-pki-theme-9.0.15-1.fc17 New packages include: * Bug #976788 - pki-ca 9.0.26 add new required option, -client_token_name * Bug #951501 - corrected JavaScript issue with big numbers * Bug #961522 - [RFE] enrollment on Windows/IE does not set an option to allow private key export * Bug #883122 - Added UTF8 to default encoding order Please try it and add some karma points if you can. Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Thu Jun 27 01:06:44 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 21:06:44 -0400 Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported In-Reply-To: <436487515.28863007.1372287832393.JavaMail.root@redhat.com> References: <1372271322.2154.6.camel@aleeredhat.laptop> <436487515.28863007.1372287832393.JavaMail.root@redhat.com> Message-ID: <1372295204.31409.9.camel@aleeredhat.laptop> On Wed, 2013-06-26 at 19:03 -0400, John Magne wrote: > Ade: > > This looks good but I have a question. > > Looking at the function you added: > > private static boolean importRequired(ArrayList masterList, String nickname) { > + if (masterList.contains(nickname)) > + return true; > + try { > + X500Name xname = new X500Name(nickname); > + for (String key: masterList) { > + try { > + X500Name xkey = new X500Name(key); > + if (xkey.equals(xname)) return true; > + } catch (IOException e) { > + // xkey not an X500Name > + } > + } > + > + } catch (IOException e) { > + // nickname is not a x500Name > + return false; > + } > + return false; > + } > > It looks like the top of this function does a String comparison just like the code you had in there but commented out already: > > if (masterList.contains(nickname)) > + return true; > > As I understand the List contains method calls the equals method of the objects involved. > > Subsequently it looks like you rifle through the whole list and do a comparison between X500Name objects, which represent distinguished names. > Why is this done? There are cases where the DN's are equivalent but their raw Strings may differ? > The list of names consists of two types of strings - nicknames like "auditSigningCert pki-tomcat CA" and subject names like "CN= CA Audit Singing Cert, O=redhat domain". The masterList also contains similar names. The first call of the contains() method does a string comparison and so handles the cases where the nicknames are the same. For the subject names, I found that this was insufficient because the strings were not exactly the same. In particular, the masterList contained entries like: "cn= CA Audit Singing Cert, o=redhat domain", while the list of names from the pk12 file contained the following: "CN= CA Audit Singing Cert, O=redhat domain" Notice the difference in case for the field names. Parsing the name as an X500Name and using the equals() method for those objects eliminates those discrepancies. Ade > thanks, > jack > > ----- Original Message ----- > > From: "Ade Lee" > > To: pki-devel at redhat.com > > Sent: Wednesday, June 26, 2013 11:28:42 AM > > Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported > > > > Make sure only the master keys and certs are imported. > > > > The key import code was written for when there was only one > > subsystem per tomcat instance, and only one subsystems certs > > and keys per p12 file. We need to ensure that only the master's > > subsystem keys and certs are imported. Otherwise, unpredictable > > behavior happens, like in Ticket 665. > > > > Please review, > > > > Thanks, > > Ade > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel From jmagne at redhat.com Thu Jun 27 01:10:19 2013 From: jmagne at redhat.com (John Magne) Date: Wed, 26 Jun 2013 21:10:19 -0400 (EDT) Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported In-Reply-To: <1372295204.31409.9.camel@aleeredhat.laptop> References: <1372271322.2154.6.camel@aleeredhat.laptop> <436487515.28863007.1372287832393.JavaMail.root@redhat.com> <1372295204.31409.9.camel@aleeredhat.laptop> Message-ID: <1143355120.28897107.1372295419964.JavaMail.root@redhat.com> Thanks for info. Therefore: ACK ----- Original Message ----- From: "Ade Lee" To: "John Magne" Cc: pki-devel at redhat.com Sent: Wednesday, June 26, 2013 6:06:44 PM Subject: Re: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported On Wed, 2013-06-26 at 19:03 -0400, John Magne wrote: > Ade: > > This looks good but I have a question. > > Looking at the function you added: > > private static boolean importRequired(ArrayList masterList, String nickname) { > + if (masterList.contains(nickname)) > + return true; > + try { > + X500Name xname = new X500Name(nickname); > + for (String key: masterList) { > + try { > + X500Name xkey = new X500Name(key); > + if (xkey.equals(xname)) return true; > + } catch (IOException e) { > + // xkey not an X500Name > + } > + } > + > + } catch (IOException e) { > + // nickname is not a x500Name > + return false; > + } > + return false; > + } > > It looks like the top of this function does a String comparison just like the code you had in there but commented out already: > > if (masterList.contains(nickname)) > + return true; > > As I understand the List contains method calls the equals method of the objects involved. > > Subsequently it looks like you rifle through the whole list and do a comparison between X500Name objects, which represent distinguished names. > Why is this done? There are cases where the DN's are equivalent but their raw Strings may differ? > The list of names consists of two types of strings - nicknames like "auditSigningCert pki-tomcat CA" and subject names like "CN= CA Audit Singing Cert, O=redhat domain". The masterList also contains similar names. The first call of the contains() method does a string comparison and so handles the cases where the nicknames are the same. For the subject names, I found that this was insufficient because the strings were not exactly the same. In particular, the masterList contained entries like: "cn= CA Audit Singing Cert, o=redhat domain", while the list of names from the pk12 file contained the following: "CN= CA Audit Singing Cert, O=redhat domain" Notice the difference in case for the field names. Parsing the name as an X500Name and using the equals() method for those objects eliminates those discrepancies. Ade > thanks, > jack > > ----- Original Message ----- > > From: "Ade Lee" > > To: pki-devel at redhat.com > > Sent: Wednesday, June 26, 2013 11:28:42 AM > > Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported > > > > Make sure only the master keys and certs are imported. > > > > The key import code was written for when there was only one > > subsystem per tomcat instance, and only one subsystems certs > > and keys per p12 file. We need to ensure that only the master's > > subsystem keys and certs are imported. Otherwise, unpredictable > > behavior happens, like in Ticket 665. > > > > Please review, > > > > Thanks, > > Ade > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Jun 27 03:05:26 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 23:05:26 -0400 Subject: [Pki-devel] [PATCH] 8.1 - fix cloning issues BZ 97145 In-Reply-To: <51CB7B07.9050907@redhat.com> References: <1372270563.2154.4.camel@aleeredhat.laptop> <51CB7B07.9050907@redhat.com> Message-ID: <1372302326.31409.11.camel@aleeredhat.laptop> checked in to branches below, bugs updated and set to modified. Ade On Wed, 2013-06-26 at 16:36 -0700, Matthew Harmsen wrote: > On 06/26/13 11:16, Ade Lee wrote: > > > This patch fixes the problems described in > > https://bugzilla.redhat.com/show_bug.cgi?id=976145 > > > > Basically, there are some errors in the logic for parsing the security > > domain for cloning installs where the master is running pre-IP > > separation software. > > > > Also, included is a fix for > > https://bugzilla.redhat.com/show_bug.cgi?id=956796 > > > > Please review. > > Thanks, > > Ade > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > ACK > > Apply these fixes to: > * PKI_8_1_ERRATA_BRANCH (8.1.1), and > * PKI_8_BRANCH (8.2) From alee at redhat.com Thu Jun 27 03:50:16 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 23:50:16 -0400 Subject: [Pki-devel] [PATCH] 135 - handle case where no subsystem certs are created In-Reply-To: <450452743.28865199.1372288554113.JavaMail.root@redhat.com> References: <1372280212.31409.1.camel@aleeredhat.laptop> <450452743.28865199.1372288554113.JavaMail.root@redhat.com> Message-ID: <1372305016.31409.12.camel@aleeredhat.laptop> Added log and pushed to master and 10.0 branch. On Wed, 2013-06-26 at 19:15 -0400, John Magne wrote: > Looks good. > > ACK. > > Question though. > > Would it make any sense to log this exception. > I suppose that is what the following construct is for: > > except KeyError as exc: > > thanks, > jack > > ----- Original Message ----- > From: "Ade Lee" > To: pki-devel at redhat.com > Sent: Wednesday, June 26, 2013 1:56:52 PM > Subject: [Pki-devel] [PATCH] 135 - handle case where no subsystem certs are created > > Modify pkispawn to handle case where no subsystemCerts are generated > > When installing clone of a KRA into an existing instance, no > new system certs are generated, and so the systemCerts parameter > is not populated. This patch addresses this issue. > > Please review. > > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Jun 27 03:50:57 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 26 Jun 2013 23:50:57 -0400 Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported In-Reply-To: <1143355120.28897107.1372295419964.JavaMail.root@redhat.com> References: <1372271322.2154.6.camel@aleeredhat.laptop> <436487515.28863007.1372287832393.JavaMail.root@redhat.com> <1372295204.31409.9.camel@aleeredhat.laptop> <1143355120.28897107.1372295419964.JavaMail.root@redhat.com> Message-ID: <1372305057.31409.13.camel@aleeredhat.laptop> Pushed to 10.0.X branch and master. On Wed, 2013-06-26 at 21:10 -0400, John Magne wrote: > Thanks for info. > > Therefore: > > ACK > > ----- Original Message ----- > From: "Ade Lee" > To: "John Magne" > Cc: pki-devel at redhat.com > Sent: Wednesday, June 26, 2013 6:06:44 PM > Subject: Re: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported > > On Wed, 2013-06-26 at 19:03 -0400, John Magne wrote: > > Ade: > > > > This looks good but I have a question. > > > > Looking at the function you added: > > > > private static boolean importRequired(ArrayList masterList, String nickname) { > > + if (masterList.contains(nickname)) > > + return true; > > + try { > > + X500Name xname = new X500Name(nickname); > > + for (String key: masterList) { > > + try { > > + X500Name xkey = new X500Name(key); > > + if (xkey.equals(xname)) return true; > > + } catch (IOException e) { > > + // xkey not an X500Name > > + } > > + } > > + > > + } catch (IOException e) { > > + // nickname is not a x500Name > > + return false; > > + } > > + return false; > > + } > > > > It looks like the top of this function does a String comparison just like the code you had in there but commented out already: > > > > if (masterList.contains(nickname)) > > + return true; > > > > As I understand the List contains method calls the equals method of the objects involved. > > > > Subsequently it looks like you rifle through the whole list and do a comparison between X500Name objects, which represent distinguished names. > > Why is this done? There are cases where the DN's are equivalent but their raw Strings may differ? > > > The list of names consists of two types of strings - nicknames like > "auditSigningCert pki-tomcat CA" and subject names like > "CN= CA Audit Singing Cert, O=redhat domain". The masterList also > contains similar names. > > The first call of the contains() method does a string comparison and so > handles the cases where the nicknames are the same. For the subject > names, I found that this was insufficient because the strings were not > exactly the same. > > In particular, the masterList contained entries like: > "cn= CA Audit Singing Cert, o=redhat domain", while the list of names > from the pk12 file contained the following: > "CN= CA Audit Singing Cert, O=redhat domain" > > Notice the difference in case for the field names. Parsing the name as > an X500Name and using the equals() method for those objects eliminates > those discrepancies. > > Ade > > > thanks, > > jack > > > > ----- Original Message ----- > > > From: "Ade Lee" > > > To: pki-devel at redhat.com > > > Sent: Wednesday, June 26, 2013 11:28:42 AM > > > Subject: [Pki-devel] [PATCH] 0134-Make-sure-only-the-master-keys-and-certs-are-imported > > > > > > Make sure only the master keys and certs are imported. > > > > > > The key import code was written for when there was only one > > > subsystem per tomcat instance, and only one subsystems certs > > > and keys per p12 file. We need to ensure that only the master's > > > subsystem keys and certs are imported. Otherwise, unpredictable > > > behavior happens, like in Ticket 665. > > > > > > Please review, > > > > > > Thanks, > > > Ade > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > From akoneru at redhat.com Thu Jun 27 12:09:12 2013 From: akoneru at redhat.com (Abhishek Koneru) Date: Thu, 27 Jun 2013 08:09:12 -0400 Subject: [Pki-devel] [PATCH] 59-2 Fixing for comments given for Patch 59 In-Reply-To: <51CA2A54.8060200@redhat.com> References: <1370032689.4953.7.camel@akoneru.redhat.com> <51AFF637.8000807@redhat.com> <1372109352.23453.28.camel@akoneru.redhat.com> <51CA2A54.8060200@redhat.com> Message-ID: <1372334952.7585.0.camel@akoneru.redhat.com> Addressed all the comments given. Pushed to master. On Tue, 2013-06-25 at 18:40 -0500, Endi Sukma Dewata wrote: > On 6/24/2013 4:29 PM, Abhishek Koneru wrote: > > Please review the patch with the changes suggested by Endi to refactor > > code inorder to maintain references to the global variables and the > > utility classes. > > > > A new class PKIDeployer is added to pkihelper.py, whose object is > > created in pkispawn/pkidestroy to hold the references and be passed to > > the PKIScriptlets. > > > > Declarations for pki_master_dict and pki_slots_dict have been moved to > > init method in pkiparser.py from pkiconfig. The compose methods are > > called in pkispawn/pkidestroy and then the references passed to the > > PKIDeployer object. > > > > This also fixes many issues of tpe E1120 reported by pylint. > > > > --Abhishek > > Some comments: > > 1. The helper class names begin with underscore (e.g. _Identity). I > don't think this is necessary. These classes will be used by scriptlet > writers, so they aren't meant to be private classes. > > 2. Some of the constructors are defined like this: > > def __init__(self, pki_master_dict, identity = None): > self.master_dict = pki_master_dict > if identity is None: > self.identity = _Identity(pki_master_dict) > else: > self.identity = identity > > Since these classes are always used with the deployer object, we can > simplify it like this: > > def __init__(self, deployer): > self.master_dict = deployer.pki_master_dict > self.identity = deployer.identity > > Using the deployer guarantees that the dicts and helper objects are > already created, so there's no need to create the objects again. > > 3. There are some trailing whitespaces. > > Everything else is fine, the code works. With the above issues fixed, ACK. > > > As future enhancement, it's possible to simplify the scriptlets further. > For example: > > deployer.file.copy_with_slot_substitution( > deployer.master_dict['pki_source_catalina_properties'], > deployer.master_dict['pki_target_catalina_properties'], > overwrite_flag=True) > > If the method is always used with values from the master_dict, the above > line can be simplified as follows: > > deployer.file.copy_with_slot_substitution( > 'pki_source_catalina_properties', > 'pki_target_catalina_properties', > overwrite_flag=True) > From alee at redhat.com Thu Jun 27 15:20:05 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Jun 2013 11:20:05 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51C9DE5C.1@redhat.com> References: <51C9DE5C.1@redhat.com> Message-ID: <1372346405.2759.38.camel@localhost.localdomain> 1. One of the decisions you made was to allow admins, agents and operators to access the same resources. So, unlike the rest of the java subsystems, we will have /tps/rest/tokens as opposed to /tps/rest/agent/tokens or /tps/rest/admin/tokens One reason one might want to add /agent or /admin is if the content of GET /tps/tokens/X is different for admins/agents/operators. So what is the difference between op=search and op=search_admin, op=view and op=view_admin, op=show and op=show_admin? etc. Is there any case where those differences need be preserved? 2. You use PUT /tps/rest/tokens/X as the operation to modify tokens. Usually REST semantics imply that the resource passed in to the PUT operation essentially replace the resource at the server. Is that your intention? I'm guessing that the resource that would be passed in is the token object returned in GET /tps/rest/tokens/foo. It would help if you defined what a token resource was. Or is your intention to send in something with an "action" parameter - in which case, the correct operation is a POST? 3. Should we be worried about a XSS attack here for modifying the state of the token? My guess is that we need to take advantage of the nonce mechanism, in which case, token state modification will require two steps. 4. You should also note that we will be sending back BAD_REQUEST (401?) when the token state transition is not permitted. 5. In the response to PUT /tokens/X, it is not necessary to return the state of the token. Rather, you should return a URL pointer to the newly modified resource. The same comment applies to the other PUT operations as well. 6. Same question about XSS for add/remove token/ add/remove user. 7. Note that the difference between op=view_activity, op=view_activity_all etc. is in the types of activities that are visible. This should be handled seamlessly in the logic used to select activity records from the db. 8. For the configuration items - audit config, profiles, profile mappings, connections, authenticators, I wonder if it makes things clearer to put them under a config bucket .. like /tps/rest/config/audit for example. 9. Is there a mapping between Profile and Profile Mapping operations and the old operations? Please put that in so we can see whether we have complete coverage. In particular, I do not see an operation to approve/enable a profile. This is important because we have Common Criteria requirements that two users are involved in the approval of a profile. In our case, IIRC we implemented it such that an admin can configure a profile but an agent must approve it. 10. In POST /tps/rest/profilemappings, you return the location of the profile mappings as well as the contents of the profile mapping resource. You should just return the location. In fact, its probably better to just return locations in general. The client would then use GET to fetch the details if needed. This comment applies to many of the resources. 11. In the PUT /tps/rest/config, we have requirements for having than one user to approve changes. Admins make changes and agents approve them if I recall correctly. You should look at the differences between the agent and admin pages. On Tue, 2013-06-25 at 13:15 -0500, Endi Sukma Dewata wrote: > Hi, > > This is the initial draft of the TPS REST interface design: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface > > Please take a look and let me know if you have any comments. Thanks! > From alee at redhat.com Thu Jun 27 16:04:54 2013 From: alee at redhat.com (Ade Lee) Date: Thu, 27 Jun 2013 12:04:54 -0400 Subject: [Pki-devel] [PATCH]136 - initial framework for restful interfaces for managing profiles Message-ID: <1372349094.2759.46.camel@localhost.localdomain> This adds the initial framework for viewing and managing profiles. At this point, only the viewing of profiles is tested. Because I make some changes to some of the objects used in Cert enrollment, some of the current tests involving enrollment may fail if they use pre-generated XML. Still, this patch is getting quite large and its time to get some eyes on it. The next patches will add the CLI code to view profiles and then to add/edit profiles. Following that, will be patches to clean up all the TODOs - like adding the relevant exceptions and auditing. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0136-Add-interfaces-for-managing-profiles.patch Type: text/x-patch Size: 80633 bytes Desc: not available URL: From edewata at redhat.com Thu Jun 27 18:23:47 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 27 Jun 2013 13:23:47 -0500 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <1372346405.2759.38.camel@localhost.localdomain> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> Message-ID: <51CC8333.5040509@redhat.com> On 6/27/2013 10:20 AM, Ade Lee wrote: > 1. One of the decisions you made was to allow admins, agents and > operators to access the same resources. So, unlike the rest of the java > subsystems, we will have /tps/rest/tokens as opposed > to /tps/rest/agent/tokens or /tps/rest/admin/tokens > > One reason one might want to add /agent or /admin is if the content of > GET /tps/tokens/X is different for admins/agents/operators. > > So what is the difference between op=search and op=search_admin, op=view > and op=view_admin, op=show and op=show_admin? etc. I'm still rebuilding my TPS environment so I can't check this myself right now, but here are the screenshots from the docs and they look pretty much identical: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Agents_Guide/operator.html#viewing-tokens https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Agents_Guide/agent.html#agent-viewing-tokens https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Agents_Guide/admin-tasks.html#admin-viewing-tokens > Is there any case where those differences need be preserved? Even if there are differences, since they are the same resources (i.e. tokens) most of the visible attributes will be the same. If there are differences between the roles, it will be handled by returning the common attributes plus the attributes visible to that role only. When creating the REST data structure we combine all possible attributes. > 2. You use PUT /tps/rest/tokens/X as the operation to modify tokens. > Usually REST semantics imply that the resource passed in to the PUT > operation essentially replace the resource at the server. > > Is that your intention? I'm guessing that the resource that would be > passed in is the token object returned in GET /tps/rest/tokens/foo. > It would help if you defined what a token resource was. Any REST resource is a partial representation of the actual object/service running on the server, meaning it may not have the full information to reconstruct the object on the server-side. So even if we PUT a resource it should be clear that we're not completely replacing the actual object on the server, but we're updating the resource with the attributes provided in the request. In case of token resource, the resource consists of the attributes returned by the GET operation which may not include everything a token has. When modifying the resource using PUT some of these attributes will be ignored because they are read-only (e.g. date created/modified), but we can still PUT a resource that we obtained earlier using GET back to the server to update some attributes. > Or is your intention to send in something with an "action" parameter - > in which case, the correct operation is a POST? I use 'action' in the modify token operation because I couldn't find a better replacement for the 'question' parameter in the original op=do_token. Ideally it should be called 'status' but there's already another attribute with that name. Any suggestion? This 'action' should actually be returned by the GET operation too. I'll add it after we finalize the name. > 3. Should we be worried about a XSS attack here for modifying the state > of the token? My guess is that we need to take advantage of the nonce > mechanism, in which case, token state modification will require two > steps. Yes, but similar to our discussion in the past, nonces or ETags can be added in a later phase without changing the interface. Since the modification is a PUT operation, and the request attributes are obtained using a GET operation done earlier, this is a two-step operation. Without the nonce or ETag the GET operation will be optional, and the client can construct the request from scratch. But later the PUT operation can require a nonce or ETag from a previous GET operation. > 4. You should also note that we will be sending back BAD_REQUEST (401?) > when the token state transition is not permitted. That should fall under "Normal application errors will return HTTP 4xx return code." We can add more details as we implement it. > 5. In the response to PUT /tokens/X, it is not necessary to return the > state of the token. Rather, you should return a URL pointer to the > newly modified resource. The same comment applies to the other PUT > operations as well. Since PUT operation in general doesn't create a new resource, and also the request is sent to the resource URL being modified, there is no need to return a new location because it will be identical. In this design the new location will only be returned on POST operations when adding a new resource, which in this case the new resource location will be different from the POST target (the resource collection). > 6. Same question about XSS for add/remove token/ add/remove user. Similarly, nonces or ETags can be added later. As described earlier, modifying users is a two-step process too with GET and PUT. Add and remove operations do not require the client to do any other operation, but it can be made so without changing the interface. The DELETE can require a GET, but I'm not sure what operation should be required before add. > 7. Note that the difference between op=view_activity, > op=view_activity_all etc. is in the types of activities that are > visible. This should be handled seamlessly in the logic used to select > activity records from the db. Yes, the interface will be the same, but depending on which roles you belong to you may get different results. > 8. For the configuration items - audit config, profiles, profile > mappings, connections, authenticators, I wonder if it makes things > clearer to put them under a config bucket .. like /tps/rest/config/audit > for example. I'd rather not do that. For now I'm using /tps/rest/config to store general settings. If there are resource-specific settings they should go to that resource subtree. For example, suppose later we want to provide interface to view audit logs, it will be stored under /tps/rest/audit/logs. The audit config can be stored in /tps/rest/audit, or maybe /tps/rest/audit/config. Imagine you're an admin looking at a web page showing the audit logs. If you want to change the audit settings you'd want to be able to click a button on that page directly. Having to go to config -> audit menu will be less intuitive. Not that this is relevant to determine the actual resource URL, but with the same principles the config should be located near the entries of that resource. It's also possible to provide two interfaces at both locations for the same resources, but there's no real need to do that now. For the other resources mentioned above, they are both the entries and the config. If we put them under config there wouldn't many (or any) things left at the top level. Even system users can also be considered a config, but unless there's a strong reason I prefer to keep them where they are now. > 9. Is there a mapping between Profile and Profile Mapping operations and > the old operations? Please put that in so we can see whether we have > complete coverage. In particular, I do not see an operation to > approve/enable a profile. This is important because we have Common > Criteria requirements that two users are involved in the approval of a > profile. In our case, IIRC we implemented it such that an admin can > configure a profile but an agent must approve it. There should be, but they are not in the docs and I have not had a chance to test all possible operations in the UI. Once I get the TPS instance back running I'll continue this. But in general we can implement something similar to the cert requests: /tps/rest/profiles/{id}/approve (all approvers will use the same URL) /tps/rest/profiles/{id}/enable > 10. In POST /tps/rest/profilemappings, you return the location of the > profile mappings as well as the contents of the profile mapping > resource. You should just return the location. In fact, its probably > better to just return locations in general. The client would then use > GET to fetch the details if needed. This comment applies to many of the > resources. In general I'd rather return the resource attributes in the POST response than requiring the client to do a separate GET later. This response acts as a receipt/acknowledgement for the add request, and it will return the actual attributes stored on the server before any other operation is done on it. This is rather important because sometimes a lazy UI won't do an extra GET because it assumes the attributes don't change, where in fact they could be normalized, ignored, or generated by the server. It also prevents a possible (although unlikely) attack that inserts an operation between the POST and GET. > 11. In the PUT /tps/rest/config, we have requirements for having than > one user to approve changes. Admins make changes and agents approve > them if I recall correctly. You should look at the differences between > the agent and admin pages. I'll take a look again after I have the TPS instance back. Is there any documents or diagrams showing the workflow of all approval processes in TPS UI? Thanks. -- Endi S. Dewata From edewata at redhat.com Thu Jun 27 21:40:05 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 27 Jun 2013 16:40:05 -0500 Subject: [Pki-devel] [PATCH]136 - initial framework for restful interfaces for managing profiles In-Reply-To: <1372349094.2759.46.camel@localhost.localdomain> References: <1372349094.2759.46.camel@localhost.localdomain> Message-ID: <51CCB135.8000907@redhat.com> On 6/27/2013 11:04 AM, Ade Lee wrote: > This adds the initial framework for viewing and managing profiles. > At this point, only the viewing of profiles is tested. > > Because I make some changes to some of the objects used in Cert > enrollment, some of the current tests involving enrollment may fail > if they use pre-generated XML. > > Still, this patch is getting quite large and its time to get some eyes > on it. > > The next patches will add the CLI code to view profiles and then to > add/edit profiles. Following that, will be patches to clean up all the > TODOs - like adding the relevant exceptions and auditing. > > Ade Some comments: 1. The log messages in CATest should say 'Enabled:' and 'Visible:' because those are the attribute names being logged: log("Enabled: " + info.isEnabled()); log("Visible: " + info.isVisible() + "\n\n"); 2. The following code in CATest can be simplified: ListIterator iter = entry.getValue().getAttrs().listIterator(); while (iter.hasNext()) { ProfileAttribute attr = iter.next(); into this: for (ProfileAttribute attr : entry.getValue().getAttrs()) { Similar code exists in CertEnrollmentRequest, BasicProfile, CertProcessor, and EnrollmentProcessor. 3. I don't think the ProfileAttribute should be changed to use IDescriptor instead of Descriptor. Are there other classes implementing IDescriptor? The type adapter for IDescriptor is defined as Descriptor.Adapter, but this adapter will do a simple typecast from IDescriptor to Descriptor and vice versa, so it probably won't work with other classes. To properly marshal any IDescriptor into Descriptor we'd have to create a new Descriptor object and initialize it with values obtained using using IDescriptor methods. I'm also not sure how unmarshal would be able to restore the original object if it's not a Descriptor. I think if there's no other types of descriptor (or if all descriptors will inherit from Descriptor) then we should just use Descriptor in ProfileAttribute. But if we need to support different descriptor types, we need to serialization the class name as well (see PKIException.Data class) and use a factory to recreate the proper object. 4. In ProfileData the inputs, outputs, and policySets attributes are declared between the method declarations. To improve readability we should keep the attributes in the beginning of the class before any method declarations. Similar issues also happens in ProfileInput and ProfileOutput. 5. The ProfileData.policySets maps a String to a Vector. I think unless there's a special need for Vector (e.g. synchronized access) we should use a more generic and light-weight Collection instead. 6. The following code in BasicProfile deleteAllProfileInputs() and deleteAllProfileInputs() can be simplified: Iterator iter = mInputIds.iterator(); while (iter.hasNext()) { String id = iter.next(); into this: for (String id : mInputIds) { 7. In ProfileService the listProfiles() is split into listEEProfiles() and listAdminProfiles() to return different results based on the visibility flag. Splitting the method doesn't prevent a user from calling a method that he's not supposed to call. To prevent that we'd have to configure ACLs, which adds maintenance. Also we probably have to write different CLI to call different methods for different roles. Instead, we could use the original method but it should check the roles of the user and determine the visibility flag based on that. 8. In ProfileService.createProfileDataInfo() the URI is constructed using String concatenation in 2 different ways: if (visibleOnly) { profileBuilder.path(profilePath.value() + "/profiles/" + profileId); } else { profileBuilder.path(profilePath.value() + "/agent/profiles/" + profileId); } ret.setProfileURL(profileBuilder.build().toString()); If we implement #7 it can be simplified like this: URI uri = profileBuilder.path(ProfileResource.class).path("{id}"). build(profileId); ret.setProfileURL(uri.toString()); 9. Some exceptions in ProfileService are being swallowed. I think at least for now we should throw an exception (either make the method throws generic Exception or wrap the exceptions in RuntimeException) so that we know if there's a problem. Later on we can revisit this and handle the exceptions properly. 10. The code in ProfileService.populateProfilePolicies() can be simplified as follows: for (Map.Entry> policySet : data.getPolicySets().entrySet()) { -- Endi S. Dewata From alee at redhat.com Fri Jun 28 14:36:24 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 28 Jun 2013 10:36:24 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51CC8333.5040509@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> Message-ID: <1372430184.2327.35.camel@aleeredhat.laptop> On Thu, 2013-06-27 at 13:23 -0500, Endi Sukma Dewata wrote: > On 6/27/2013 10:20 AM, Ade Lee wrote: > > 1. One of the decisions you made was to allow admins, agents and > > operators to access the same resources. So, unlike the rest of the java > > subsystems, we will have /tps/rest/tokens as opposed > > to /tps/rest/agent/tokens or /tps/rest/admin/tokens > > > > One reason one might want to add /agent or /admin is if the content of > > GET /tps/tokens/X is different for admins/agents/operators. > > > > So what is the difference between op=search and op=search_admin, op=view > > and op=view_admin, op=show and op=show_admin? etc. > > I'm still rebuilding my TPS environment so I can't check this myself > right now, but here are the screenshots from the docs and they look > pretty much identical: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Agents_Guide/operator.html#viewing-tokens > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Agents_Guide/agent.html#agent-viewing-tokens > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Agents_Guide/admin-tasks.html#admin-viewing-tokens > > > Is there any case where those differences need be preserved? > > Even if there are differences, since they are the same resources (i.e. > tokens) most of the visible attributes will be the same. If there are > differences between the roles, it will be handled by returning the > common attributes plus the attributes visible to that role only. When > creating the REST data structure we combine all possible attributes. > I agree that there are more likely than not insufficient differences between the representations of the resources for each role. Part of the reason we chose to keep the calls separate for the other subsystems is because of the different authentication method for each interface. Agent and admin required client auth, ee required no auth. This is not true for the TPS UI - all intefaces require client auth or otherwise. > > 2. You use PUT /tps/rest/tokens/X as the operation to modify tokens. > > Usually REST semantics imply that the resource passed in to the PUT > > operation essentially replace the resource at the server. > > > > Is that your intention? I'm guessing that the resource that would be > > passed in is the token object returned in GET /tps/rest/tokens/foo. > > It would help if you defined what a token resource was. > > Any REST resource is a partial representation of the actual > object/service running on the server, meaning it may not have the full > information to reconstruct the object on the server-side. So even if we > PUT a resource it should be clear that we're not completely replacing > the actual object on the server, but we're updating the resource with > the attributes provided in the request. > > In case of token resource, the resource consists of the attributes > returned by the GET operation which may not include everything a token > has. When modifying the resource using PUT some of these attributes will > be ignored because they are read-only (e.g. date created/modified), but > we can still PUT a resource that we obtained earlier using GET back to > the server to update some attributes. > Agreed. > > Or is your intention to send in something with an "action" parameter - > > in which case, the correct operation is a POST? > > I use 'action' in the modify token operation because I couldn't find a > better replacement for the 'question' parameter in the original > op=do_token. Ideally it should be called 'status' but there's already > another attribute with that name. Any suggestion? This 'action' should > actually be returned by the GET operation too. I'll add it after we > finalize the name. do_token?question=X is essentially an operation where you are attempting to set the state of the token resource - for example, from "active" to "lost". There is no need for an additional parameter. > > > 3. Should we be worried about a XSS attack here for modifying the state > > of the token? My guess is that we need to take advantage of the nonce > > mechanism, in which case, token state modification will require two > > steps. > > Yes, but similar to our discussion in the past, nonces or ETags can be > added in a later phase without changing the interface. Since the > modification is a PUT operation, and the request attributes are obtained > using a GET operation done earlier, this is a two-step operation. > Without the nonce or ETag the GET operation will be optional, and the > client can construct the request from scratch. But later the PUT > operation can require a nonce or ETag from a previous GET operation. > OK, please put the nonce in the design. We dont want to forget it. > > 4. You should also note that we will be sending back BAD_REQUEST (401?) > > when the token state transition is not permitted. > > That should fall under "Normal application errors will return HTTP 4xx > return code." We can add more details as we implement it. > Right, I'm just pointing this out because in this case, there is a state machine which determines which operations are successful. From the point of view of the API, doing a token transition is just an attempt to set the state of the token differently, but unlike something simple like just changing an attribute value, the operation is subject to the results of a state machine. > > 5. In the response to PUT /tokens/X, it is not necessary to return the > > state of the token. Rather, you should return a URL pointer to the > > newly modified resource. The same comment applies to the other PUT > > operations as well. > > Since PUT operation in general doesn't create a new resource, and also > the request is sent to the resource URL being modified, there is no need > to return a new location because it will be identical. In this design > the new location will only be returned on POST operations when adding a > new resource, which in this case the new resource location will be > different from the POST target (the resource collection). > Agreed. But in PUT /tokens/X, you return state information. This is not necessary. You should probably return nothing - other than status. > > 6. Same question about XSS for add/remove token/ add/remove user. > > Similarly, nonces or ETags can be added later. As described earlier, > modifying users is a two-step process too with GET and PUT. Add and > remove operations do not require the client to do any other operation, > but it can be made so without changing the interface. The DELETE can > require a GET, but I'm not sure what operation should be required before > add. > Yeah - we need to think about ADD. Being able to add a privileged user for example by XSS would be troubling. > > 7. Note that the difference between op=view_activity, > > op=view_activity_all etc. is in the types of activities that are > > visible. This should be handled seamlessly in the logic used to select > > activity records from the db. > > Yes, the interface will be the same, but depending on which roles you > belong to you may get different results. > > > 8. For the configuration items - audit config, profiles, profile > > mappings, connections, authenticators, I wonder if it makes things > > clearer to put them under a config bucket .. like /tps/rest/config/audit > > for example. > > I'd rather not do that. For now I'm using /tps/rest/config to store > general settings. If there are resource-specific settings they should go > to that resource subtree. > > For example, suppose later we want to provide interface to view audit > logs, it will be stored under /tps/rest/audit/logs. The audit config can > be stored in /tps/rest/audit, or maybe /tps/rest/audit/config. Imagine > you're an admin looking at a web page showing the audit logs. If you > want to change the audit settings you'd want to be able to click a > button on that page directly. Having to go to config -> audit menu will > be less intuitive. Not that this is relevant to determine the actual > resource URL, but with the same principles the config should be located > near the entries of that resource. It's also possible to provide two > interfaces at both locations for the same resources, but there's no real > need to do that now. > > For the other resources mentioned above, they are both the entries and > the config. If we put them under config there wouldn't many (or any) > things left at the top level. Even system users can also be considered a > config, but unless there's a strong reason I prefer to keep them where > they are now. > OK. > > 9. Is there a mapping between Profile and Profile Mapping operations and > > the old operations? Please put that in so we can see whether we have > > complete coverage. In particular, I do not see an operation to > > approve/enable a profile. This is important because we have Common > > Criteria requirements that two users are involved in the approval of a > > profile. In our case, IIRC we implemented it such that an admin can > > configure a profile but an agent must approve it. > > There should be, but they are not in the docs and I have not had a > chance to test all possible operations in the UI. Once I get the TPS > instance back running I'll continue this. But in general we can > implement something similar to the cert requests: > > /tps/rest/profiles/{id}/approve (all approvers will use the same URL) > /tps/rest/profiles/{id}/enable > Thats fine - lets make sure we get those operations in. > > 10. In POST /tps/rest/profilemappings, you return the location of the > > profile mappings as well as the contents of the profile mapping > > resource. You should just return the location. In fact, its probably > > better to just return locations in general. The client would then use > > GET to fetch the details if needed. This comment applies to many of the > > resources. > > In general I'd rather return the resource attributes in the POST > response than requiring the client to do a separate GET later. This > response acts as a receipt/acknowledgement for the add request, and it > will return the actual attributes stored on the server before any other > operation is done on it. This is rather important because sometimes a > lazy UI won't do an extra GET because it assumes the attributes don't > change, where in fact they could be normalized, ignored, or generated by > the server. It also prevents a possible (although unlikely) attack that > inserts an operation between the POST and GET. > I guess you are suggesting the same for PUT requests as above. I'm not sure whether this is vaid reasoning or not. Just because you see what has been posted (or PUT) in the server does not mean that this data has not been changed the next time the data is accessed. If anything, returning this data encourages lazy clients. The fact is though that we will have to implement nonces and possibly etags, and so GETs will become mandatory for any changes. > > 11. In the PUT /tps/rest/config, we have requirements for having than > > one user to approve changes. Admins make changes and agents approve > > them if I recall correctly. You should look at the differences between > > the agent and admin pages. > > I'll take a look again after I have the TPS instance back. Is there any > documents or diagrams showing the workflow of all approval processes in > TPS UI? Thanks. > The CC docs are probably the best bet for that (other than looking at the code). From edewata at redhat.com Sat Jun 29 04:57:43 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 28 Jun 2013 23:57:43 -0500 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <1372430184.2327.35.camel@aleeredhat.laptop> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> Message-ID: <51CE6947.3020707@redhat.com> On 6/28/2013 9:36 AM, Ade Lee wrote: >>> Or is your intention to send in something with an "action" parameter - >>> in which case, the correct operation is a POST? >> >> I use 'action' in the modify token operation because I couldn't find a >> better replacement for the 'question' parameter in the original >> op=do_token. Ideally it should be called 'status' but there's already >> another attribute with that name. Any suggestion? This 'action' should >> actually be returned by the GET operation too. I'll add it after we >> finalize the name. > > do_token?question=X is essentially an operation where you are attempting > to set the state of the token resource - for example, from "active" to > "lost". There is no need for an additional parameter. I added a Change Token State operation: http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Token_State As discussed, for now we'll call this parameter 'next state', which will update the status & reason depending on the current state of the token. >>> 3. Should we be worried about a XSS attack here for modifying the state >>> of the token? My guess is that we need to take advantage of the nonce >>> mechanism, in which case, token state modification will require two >>> steps. >> >> Yes, but similar to our discussion in the past, nonces or ETags can be >> added in a later phase without changing the interface. Since the >> modification is a PUT operation, and the request attributes are obtained >> using a GET operation done earlier, this is a two-step operation. >> Without the nonce or ETag the GET operation will be optional, and the >> client can construct the request from scratch. But later the PUT >> operation can require a nonce or ETag from a previous GET operation. > > OK, please put the nonce in the design. We dont want to forget it. I added two sections related to this: http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Concurrency_Control http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Vulnerabilities >>> 4. You should also note that we will be sending back BAD_REQUEST (401?) >>> when the token state transition is not permitted. >> >> That should fall under "Normal application errors will return HTTP 4xx >> return code." We can add more details as we implement it. > > Right, I'm just pointing this out because in this case, there is a state > machine which determines which operations are successful. From the > point of view of the API, doing a token transition is just an attempt to > set the state of the token differently, but unlike something simple like > just changing an attribute value, the operation is subject to the > results of a state machine. I noted that in the response of Change Token State: http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Token_State >>> 5. In the response to PUT /tokens/X, it is not necessary to return the >>> state of the token. Rather, you should return a URL pointer to the >>> newly modified resource. The same comment applies to the other PUT >>> operations as well. >> >> Since PUT operation in general doesn't create a new resource, and also >> the request is sent to the resource URL being modified, there is no need >> to return a new location because it will be identical. In this design >> the new location will only be returned on POST operations when adding a >> new resource, which in this case the new resource location will be >> different from the POST target (the resource collection). >> > Agreed. But in PUT /tokens/X, you return state information. This is > not necessary. You should probably return nothing - other than status. See explanation in #10. >>> 6. Same question about XSS for add/remove token/ add/remove user. >> >> Similarly, nonces or ETags can be added later. As described earlier, >> modifying users is a two-step process too with GET and PUT. Add and >> remove operations do not require the client to do any other operation, >> but it can be made so without changing the interface. The DELETE can >> require a GET, but I'm not sure what operation should be required before >> add. >> > Yeah - we need to think about ADD. Being able to add a privileged user > for example by XSS would be troubling. I think we're mixing up CSRF and XSS. Nonces will be useful to prevent CSRF. XSS can be prevented by encoding/escaping the values. If we implement a single-page Web UI (like IPA Web UI) the client can obtain a nonce during login, then the UI will keep the nonce in memory throughout the session and use it for all update requests including add (the nonce should really be called CSRF token). CSRF attack usually will open a new page, so it will not be able to know the nonce. If we implement a multi-page Web UI (like the current Dogtag UI), the add operation can be done in 2 steps. The first page will generate the nonce, then the second page will execute the operation. >>> 9. Is there a mapping between Profile and Profile Mapping operations and >>> the old operations? Please put that in so we can see whether we have >>> complete coverage. In particular, I do not see an operation to >>> approve/enable a profile. This is important because we have Common >>> Criteria requirements that two users are involved in the approval of a >>> profile. In our case, IIRC we implemented it such that an admin can >>> configure a profile but an agent must approve it. >> >> There should be, but they are not in the docs and I have not had a >> chance to test all possible operations in the UI. Once I get the TPS >> instance back running I'll continue this. But in general we can >> implement something similar to the cert requests: >> >> /tps/rest/profiles/{id}/approve (all approvers will use the same URL) >> /tps/rest/profiles/{id}/enable >> > Thats fine - lets make sure we get those operations in. I added the missing mappings. I also added a Change Profile State operation: http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Profile_State >>> 10. In POST /tps/rest/profilemappings, you return the location of the >>> profile mappings as well as the contents of the profile mapping >>> resource. You should just return the location. In fact, its probably >>> better to just return locations in general. The client would then use >>> GET to fetch the details if needed. This comment applies to many of the >>> resources. >> >> In general I'd rather return the resource attributes in the POST >> response than requiring the client to do a separate GET later. This >> response acts as a receipt/acknowledgement for the add request, and it >> will return the actual attributes stored on the server before any other >> operation is done on it. This is rather important because sometimes a >> lazy UI won't do an extra GET because it assumes the attributes don't >> change, where in fact they could be normalized, ignored, or generated by >> the server. It also prevents a possible (although unlikely) attack that >> inserts an operation between the POST and GET. > > I guess you are suggesting the same for PUT requests as above. > I'm not sure whether this is vaid reasoning or not. Just because you > see what has been posted (or PUT) in the server does not mean that this > data has not been changed the next time the data is accessed. There's never any guarantee that the data we get (either from PUT, POST, or even GET) has not been changed when we submit it for another update operation. The advantage of returning the data in PUT/POST response is we're pushing the updated data to the client's feet. > If anything, returning this data encourages lazy clients. On the contrary, by returning the data in the PUT/POST response the client will have little reason not to use it. If the client has no intention to get the new data anyway (either from PUT/POST response or by doing another GET) there's nothing we can do about it. But if the client wants to get the new data, using PUT/POST response is a much cheaper option. Compare the following code: user = users.update(user); with this: users.update(user); user = users.get(user.getId()); > The fact is > though that we will have to implement nonces and possibly etags, and so > GETs will become mandatory for any changes. Not necessarily. ETag is only an optimistic lock; it's not a guarantee that the data won't change. The PUT/POST response will also provide ETag. Also see comment #6, we may be able to reuse the nonce. If there's nobody else updating the same data, we could reuse the PUT/POST response and the ETag that came with it to make subsequent update. So we're still using a two-step update process, but the 2nd step of the first update may become the 1st step of the second update. See also the Concurrency Control section in the wiki page. Imagine this, you updated a user, then you went to do some other operations. Then you came back to this user and edited it again. If there's nobody else changing the user, then the new data and ETag that you got from the first update would still be valid. But if first update happened a long time ago, the client may decide according to the caching policy that the data has expired and then issue a GET to get a newer data and ETag. >>> 11. In the PUT /tps/rest/config, we have requirements for having than >>> one user to approve changes. Admins make changes and agents approve >>> them if I recall correctly. You should look at the differences between >>> the agent and admin pages. >> >> I'll take a look again after I have the TPS instance back. Is there any >> documents or diagrams showing the workflow of all approval processes in >> TPS UI? Thanks. >> > The CC docs are probably the best bet for that (other than looking at > the code). The only approval process I saw in the UI is for profiles, not for general config. Could you point me to a specific page in the docs? Thanks. -- Endi S. Dewata From alee at redhat.com Sat Jun 29 19:16:41 2013 From: alee at redhat.com (Ade Lee) Date: Sat, 29 Jun 2013 15:16:41 -0400 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <51CE6947.3020707@redhat.com> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> Message-ID: <1372533401.2327.45.camel@aleeredhat.laptop> I'll respond to the comments below in a separate email. One thing I just noticed though is the operation to add a token. You have POST /tokens passing in the tokenId. POST /tokens is only used when creating a resource when the URL of the resource is unknown -- ie. it will be specified by the server. An example of this is POST /certrequests which returns the URL of the request /certrequests/0xf00 where 0xf00 is the request ID as assigned by the server. In this case, the token ID is what is being passed in. So we know the resultant URL when the resource is created. There are two options instead: a) PUT /tokens/tokenID b) POST /tokens/tokenID My preference is a) but of course the advantage of (b) is that there is a distinction between an ADD and a modify operation. The same comment applies to all the ADD operations in the design. On Fri, 2013-06-28 at 23:57 -0500, Endi Sukma Dewata wrote: > On 6/28/2013 9:36 AM, Ade Lee wrote: > >>> Or is your intention to send in something with an "action" parameter - > >>> in which case, the correct operation is a POST? > >> > >> I use 'action' in the modify token operation because I couldn't find a > >> better replacement for the 'question' parameter in the original > >> op=do_token. Ideally it should be called 'status' but there's already > >> another attribute with that name. Any suggestion? This 'action' should > >> actually be returned by the GET operation too. I'll add it after we > >> finalize the name. > > > > do_token?question=X is essentially an operation where you are attempting > > to set the state of the token resource - for example, from "active" to > > "lost". There is no need for an additional parameter. > > I added a Change Token State operation: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Token_State > > As discussed, for now we'll call this parameter 'next state', which will > update the status & reason depending on the current state of the token. > > >>> 3. Should we be worried about a XSS attack here for modifying the state > >>> of the token? My guess is that we need to take advantage of the nonce > >>> mechanism, in which case, token state modification will require two > >>> steps. > >> > >> Yes, but similar to our discussion in the past, nonces or ETags can be > >> added in a later phase without changing the interface. Since the > >> modification is a PUT operation, and the request attributes are obtained > >> using a GET operation done earlier, this is a two-step operation. > >> Without the nonce or ETag the GET operation will be optional, and the > >> client can construct the request from scratch. But later the PUT > >> operation can require a nonce or ETag from a previous GET operation. > > > > OK, please put the nonce in the design. We dont want to forget it. > > I added two sections related to this: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Concurrency_Control > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Vulnerabilities > > >>> 4. You should also note that we will be sending back BAD_REQUEST (401?) > >>> when the token state transition is not permitted. > >> > >> That should fall under "Normal application errors will return HTTP 4xx > >> return code." We can add more details as we implement it. > > > > Right, I'm just pointing this out because in this case, there is a state > > machine which determines which operations are successful. From the > > point of view of the API, doing a token transition is just an attempt to > > set the state of the token differently, but unlike something simple like > > just changing an attribute value, the operation is subject to the > > results of a state machine. > > I noted that in the response of Change Token State: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Token_State > > >>> 5. In the response to PUT /tokens/X, it is not necessary to return the > >>> state of the token. Rather, you should return a URL pointer to the > >>> newly modified resource. The same comment applies to the other PUT > >>> operations as well. > >> > >> Since PUT operation in general doesn't create a new resource, and also > >> the request is sent to the resource URL being modified, there is no need > >> to return a new location because it will be identical. In this design > >> the new location will only be returned on POST operations when adding a > >> new resource, which in this case the new resource location will be > >> different from the POST target (the resource collection). > >> > > Agreed. But in PUT /tokens/X, you return state information. This is > > not necessary. You should probably return nothing - other than status. > > See explanation in #10. > > >>> 6. Same question about XSS for add/remove token/ add/remove user. > >> > >> Similarly, nonces or ETags can be added later. As described earlier, > >> modifying users is a two-step process too with GET and PUT. Add and > >> remove operations do not require the client to do any other operation, > >> but it can be made so without changing the interface. The DELETE can > >> require a GET, but I'm not sure what operation should be required before > >> add. > >> > > Yeah - we need to think about ADD. Being able to add a privileged user > > for example by XSS would be troubling. > > I think we're mixing up CSRF and XSS. Nonces will be useful to prevent > CSRF. XSS can be prevented by encoding/escaping the values. > > If we implement a single-page Web UI (like IPA Web UI) the client can > obtain a nonce during login, then the UI will keep the nonce in memory > throughout the session and use it for all update requests including add > (the nonce should really be called CSRF token). CSRF attack usually will > open a new page, so it will not be able to know the nonce. > > If we implement a multi-page Web UI (like the current Dogtag UI), the > add operation can be done in 2 steps. The first page will generate the > nonce, then the second page will execute the operation. > > >>> 9. Is there a mapping between Profile and Profile Mapping operations and > >>> the old operations? Please put that in so we can see whether we have > >>> complete coverage. In particular, I do not see an operation to > >>> approve/enable a profile. This is important because we have Common > >>> Criteria requirements that two users are involved in the approval of a > >>> profile. In our case, IIRC we implemented it such that an admin can > >>> configure a profile but an agent must approve it. > >> > >> There should be, but they are not in the docs and I have not had a > >> chance to test all possible operations in the UI. Once I get the TPS > >> instance back running I'll continue this. But in general we can > >> implement something similar to the cert requests: > >> > >> /tps/rest/profiles/{id}/approve (all approvers will use the same URL) > >> /tps/rest/profiles/{id}/enable > >> > > Thats fine - lets make sure we get those operations in. > > I added the missing mappings. I also added a Change Profile State operation: > http://pki.fedoraproject.org/wiki/TPS_REST_Interface#Change_Profile_State > > >>> 10. In POST /tps/rest/profilemappings, you return the location of the > >>> profile mappings as well as the contents of the profile mapping > >>> resource. You should just return the location. In fact, its probably > >>> better to just return locations in general. The client would then use > >>> GET to fetch the details if needed. This comment applies to many of the > >>> resources. > >> > >> In general I'd rather return the resource attributes in the POST > >> response than requiring the client to do a separate GET later. This > >> response acts as a receipt/acknowledgement for the add request, and it > >> will return the actual attributes stored on the server before any other > >> operation is done on it. This is rather important because sometimes a > >> lazy UI won't do an extra GET because it assumes the attributes don't > >> change, where in fact they could be normalized, ignored, or generated by > >> the server. It also prevents a possible (although unlikely) attack that > >> inserts an operation between the POST and GET. > > > > I guess you are suggesting the same for PUT requests as above. > > I'm not sure whether this is vaid reasoning or not. Just because you > > see what has been posted (or PUT) in the server does not mean that this > > data has not been changed the next time the data is accessed. > > There's never any guarantee that the data we get (either from PUT, POST, > or even GET) has not been changed when we submit it for another update > operation. The advantage of returning the data in PUT/POST response is > we're pushing the updated data to the client's feet. > > > If anything, returning this data encourages lazy clients. > > On the contrary, by returning the data in the PUT/POST response the > client will have little reason not to use it. If the client has no > intention to get the new data anyway (either from PUT/POST response or > by doing another GET) there's nothing we can do about it. But if the > client wants to get the new data, using PUT/POST response is a much > cheaper option. > > Compare the following code: > > user = users.update(user); > > with this: > > users.update(user); > user = users.get(user.getId()); > > > The fact is > > though that we will have to implement nonces and possibly etags, and so > > GETs will become mandatory for any changes. > > Not necessarily. ETag is only an optimistic lock; it's not a guarantee > that the data won't change. The PUT/POST response will also provide > ETag. Also see comment #6, we may be able to reuse the nonce. > > If there's nobody else updating the same data, we could reuse the > PUT/POST response and the ETag that came with it to make subsequent > update. So we're still using a two-step update process, but the 2nd step > of the first update may become the 1st step of the second update. See > also the Concurrency Control section in the wiki page. > > Imagine this, you updated a user, then you went to do some other > operations. Then you came back to this user and edited it again. If > there's nobody else changing the user, then the new data and ETag that > you got from the first update would still be valid. But if first update > happened a long time ago, the client may decide according to the caching > policy that the data has expired and then issue a GET to get a newer > data and ETag. > > >>> 11. In the PUT /tps/rest/config, we have requirements for having than > >>> one user to approve changes. Admins make changes and agents approve > >>> them if I recall correctly. You should look at the differences between > >>> the agent and admin pages. > >> > >> I'll take a look again after I have the TPS instance back. Is there any > >> documents or diagrams showing the workflow of all approval processes in > >> TPS UI? Thanks. > >> > > The CC docs are probably the best bet for that (other than looking at > > the code). > > The only approval process I saw in the UI is for profiles, not for > general config. Could you point me to a specific page in the docs? > > Thanks. > From edewata at redhat.com Sat Jun 29 21:12:58 2013 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sat, 29 Jun 2013 16:12:58 -0500 Subject: [Pki-devel] TPS REST interface design In-Reply-To: <1372533401.2327.45.camel@aleeredhat.laptop> References: <51C9DE5C.1@redhat.com> <1372346405.2759.38.camel@localhost.localdomain> <51CC8333.5040509@redhat.com> <1372430184.2327.35.camel@aleeredhat.laptop> <51CE6947.3020707@redhat.com> <1372533401.2327.45.camel@aleeredhat.laptop> Message-ID: <51CF4DDA.4080005@redhat.com> On 6/29/2013 2:16 PM, Ade Lee wrote: > One thing I just noticed though is the operation to add a token. > You have POST /tokens passing in the tokenId. > > POST /tokens is only used when creating a resource when the URL of the > resource is unknown -- ie. it will be specified by the server. An > example of this is POST /certrequests which returns the URL of the > request /certrequests/0xf00 where 0xf00 is the request ID as assigned by > the server. That is one way to use POST, but in general it doesn't always have to be that limited. Consider the ID as an optional parameter. You can specify it, but it's not specified the server could generate a new ID automatically (not that we want to do that for this case). For the client it would be easier to use the same operation to create a new entry, with or without the ID. The operation that will work for both cases is POST-ing into the collection. I don't think this is violating any REST guidelines. It's also consistent with the add operation for the existing user and group resources. > In this case, the token ID is what is being passed in. So we know the > resultant URL when the resource is created. There are two options > instead: > > a) PUT /tokens/tokenID > b) POST /tokens/tokenID > > My preference is a) but of course the advantage of (b) is that there is > a distinction between an ADD and a modify operation. > > The same comment applies to all the ADD operations in the design. The problem with (a) is that without ETag there's a risk overwriting an existing token, and there's no warning or error message when that happens. While ETag is desired, it should be optional (can we guarantee all clients will support ETag?) and may not get implemented right away. If we POST to the collection the server can reject it if the entry already exists. Also, naturally an add operation is not idempotent, so we should not use PUT. Option (b) is a little weird because usually we expect the resource would already exist when we POST. POST-ing to the collection is fine because the collection always exists. -- Endi S. Dewata From mkosek at redhat.com Mon Jun 17 07:54:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Jun 2013 07:54:16 -0000 Subject: [Pki-devel] New builds in bodhi In-Reply-To: <1371232875.2788.3.camel@aleeredhat.laptop> References: <1371232875.2788.3.camel@aleeredhat.laptop> Message-ID: <51BEC0A5.9030000@redhat.com> On 06/14/2013 08:01 PM, Ade Lee wrote: > Hi all, > > New builds have been posted to bodhi for pki-core-10.0.3-2 (F18 and F19) > and tomcatjss (7.0.0-5 F18) and (7.1.0-3 F19). > > Please test and provide karma. F19 testing is particularly important > because the change deadline is Tuesday. > > Ade > I tested it both with F19's FreeIPA and it works fine. Karma given - we now hit the Stable karma threshold for both packages. Martin