From edewata at redhat.com Thu Mar 1 01:43:19 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 29 Feb 2012 19:43:19 -0600 Subject: [Pki-devel] [PATCH] 25 Fixed DRM REST interface to use BigInteger. In-Reply-To: <4F4D2E10.7010502@redhat.com> References: <4F4D2E10.7010502@redhat.com> Message-ID: <4F4ED437.8090908@redhat.com> On 2/28/2012 1:42 PM, Endi Sukma Dewata wrote: > The Key ID and request ID previously were Strings. They have been > converted into BigIntegers. > > Ticket #94 > > Passed smoke test. Revised the patch to use KeyId and RequestId classes which internally use BigInteger. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0025-1-Fixed-DRM-REST-interface-to-use-BigInteger.patch Type: text/x-patch Size: 56100 bytes Desc: not available URL: From awnuk at redhat.com Thu Mar 1 01:58:15 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 29 Feb 2012 17:58:15 -0800 Subject: [Pki-devel] [Patch] Option to change for default algorithms In-Reply-To: <4F4E687D.7000201@redhat.com> References: <4F4E65AA.4000502@redhat.com> <4F4E687D.7000201@redhat.com> Message-ID: <4F4ED7B7.3080808@redhat.com> On 02/29/2012 10:03 AM, Matthew Harmsen wrote: > On 02/29/12 09:51, Andrew Wnuk wrote: >> RSA should be default selection for transport, storage, and audit >> keys till ECC is fully implemented. >> >> Bug #787806. >> >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > ACK Pushed to DOGTAG_9_BRANCH. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Thu Mar 1 02:42:11 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 29 Feb 2012 18:42:11 -0800 Subject: [Pki-devel] [Patch] Option to change default algorithms In-Reply-To: <4F4ED7B7.3080808@redhat.com> References: <4F4E65AA.4000502@redhat.com> <4F4E687D.7000201@redhat.com> <4F4ED7B7.3080808@redhat.com> Message-ID: <4F4EE203.9060002@redhat.com> On 02/29/2012 05:58 PM, Andrew Wnuk wrote: > On 02/29/2012 10:03 AM, Matthew Harmsen wrote: >> On 02/29/12 09:51, Andrew Wnuk wrote: >>> RSA should be default selection for transport, storage, and audit >>> keys till ECC is fully implemented. >>> >>> Bug #787806. >>> >>> >>> >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> ACK > Pushed to DOGTAG_9_BRANCH. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Pushed to master. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Fri Mar 2 03:53:43 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 01 Mar 2012 19:53:43 -0800 Subject: [Pki-devel] [PATCH] 0001-Python-pki-deploy-framework.patch Message-ID: <4F504447.8080306@redhat.com> The following patch includes the initial framework of a Python 'pki-deploy' framework as discussed in 'http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment'. It contains ONLY the very start of some scriptlet work, and is by no means complete at this stage. Please review -- testing can be performed by applying this patch to a 'master' repo, building it, and installing the 'pki-deploy' noarch RPM. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Python-pki-deploy-framework.patch Type: text/x-patch Size: 72832 bytes Desc: not available URL: From orquidea.peramor at gmail.com Fri Mar 2 17:34:44 2012 From: orquidea.peramor at gmail.com (Orquidea Salt mas) Date: Fri, 2 Mar 2012 18:34:44 +0100 Subject: [Pki-devel] =?iso-8859-1?q?Reb=E9late_by_self-management=2C_first?= =?iso-8859-1?q?_project_of_free_software_by_which_we_bet_all_/_Reb?= =?iso-8859-1?q?=E9late_por_la_autogesti=F3n=2C_primer_proyecto_de_?= =?iso-8859-1?q?software_libre_por_el_que_apostamos_todas?= Message-ID: Ingl?s : Many already we have contributed to the first project of free software dedicated to self-management in this campaign of collective financing, it collaborates and it spreads!/ Beginning campaign collective financing http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion?lang=en Login to enter with user of social networks and for would register in Goteo : http://www.goteo.org/user/login?lang=en Rebelaos! Publication by self-management A massive publication that floods the public transport, the work centers, the parks, the consumption centers, by means of distribution of 500,000 gratuitous units, acting simultaneously in all sides and nowhere. We announce the main tool of a vestibule Web for the management of self-sustaining resources by means of Drupal, in addition in the publication there will be an article dedicated to free software, hardware, It is being prepared in ingl?s, the machinery You can see more details in the index of the publication https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf . A computer system that allows us to share resources in all the scopes of our life so that we do not have to generate means different for each subject nor for each territory. A point of contact digitalis to generate projects of life outside Capitalism and to margin of the State. A tool to spread and to impel the social transformation through the resources that will set out in their contents around self-management, the autoorganizaci?n, the disobedience and the collective action. In which the capitalist system goes to the collapse, in a while immersed in a deep systemic crisis (ecological, political and economic, but mainly of values), where individual and collective of people they are being lacking of his fundamental rights, is necessary to develop a horizontal collective process where all the human beings we pruned to interact in equality of conditions and freedom. To interact means to relate to us (as much human as economically), to communicate to us, to cover our basic needs, to generate and to protect communal properties, to know and to provide collective solutions us problematic that our lives interfere. We want abrir a breach within normality in the monotonous life state-capitalist, a day anyone, that finally will not be any day. By means of this publication we try: - To drive a horizontal collective process where all and all we pruned to interact in equality of conditions and freedom. - To create communications network between the people it jeopardize with the change and arranged to act. - To find collective solutions to problematic that our lives interfere - To facilitate the access to resources that make possible self-management. - To participate in the construction of networks of mutual support, generated horizontals, asamblearias and from the base. - To publish all this information in an attractive format stops to facilitate the access to all the society. There are 15 days remaining for the upcoming March 15, the day that will come Rebelaos!, Magazine for the selfmanagement Today, we issue the cover of Rebelaos! (Castilian version) that can be displayed on the following link: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos The contents of the store owners to us by 15 March. Do you? Do you keep on 15 March? In addition, we have over 200 distribution nodes, distributed throughout the Spanish state. Check the map: https://afinidadrebelde.crowdmap.com/ On the other hand, the funding campaign continues to move and still have 12 days to collect the remaining 6,000 euros. We can all make a bit for all the grains of sand become a great beach on March 15. You can access the co-financing campaign: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Rebel Affinity group www.rebelaos.net ------------------------------------------------------------------------------- Castellano: Muchos ya hemos aportado al primer proyecto de software libre dedicado a la la financiaci?n colectiva, colabora y diffunde !!!!! Inicio campa?a financiaci?n colectiva goteo.org www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Link para registrarse en Goteo y acceder a redes sociales para colaborar en la difus?n http://www.goteo.org/user/login ?Rebelaos! Publicaci?n por la autogesti?n Una publicaci?n masiva que inunde el transporte p?blico, los centros de trabajo, los parques, los centros de consumo, mediante la distribuci?n de 500.000 ejemplares gratuitos, actuando simult?neamente en todos lados y en ninguna parte. Anunciamos la herramienta principal de un portal web para la gesti?n de recursos autogestionados mediante Drupal, adem?s en la publicaci?n habr? un art?culo dedicado al software libre, el hardware, la maquinaria... Puedes ver m?s detalles en el ?ndice de la publicaci?n https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf Un sistema inf?rmatico que nos permita compartir recursos en todos los ?mbitos de nuestra vida de forma que no tengamos que generar un medio distinto para cada tema ni para cada territorio. Un punto de encuentro digital para generar proyectos de vida fuera del capitalismo y al margen del Estado. Una herramienta para difundir e impulsar la transformaci?n social a trav?s de los recursos que se propondr?n en sus contenidos en torno a la autogesti?n, la autoorganizaci?n, la desobediencia y la acci?n colectiva. En un momento en que el sistema capitalista se dirige al colapso, inmerso en una profunda crisis sist?mica (ecol?gica, pol?tica y econ?mica, pero principalmente de valores), donde individuos y colectivos de personas est?n siendo desprovistos de sus derechos fundamentales, es necesario desarrollar un proceso colectivo horizontal donde todos los seres humanos podamos interactuar en igualdad de condiciones y en libertad. Interactuar significa relacionarnos (tanto humana como econ?micamente), comunicarnos, cubrir nuestras necesidades b?sicas, generar y proteger bienes comunes, conocernos y dar soluciones colectivas a problem?ticas que interfieren nuestras vidas. Queremos abrir una brecha dentro de la normalidad en la mon?tona vida estatal-capitalista, un d?a cualquiera, que finalmente no ser? cualquier d?a. Mediante esta publicaci?n pretendemos: - Impulsar un proceso colectivo horizontal donde todos y todas podamos interactuar en igualdad de condiciones y en libertad. - Crear red de comunicaciones entre las personas comprometidas con el cambio y dispuestas a actuar. - Encontrar soluciones colectivas a problem?ticas que interfieren nuestras vidas. - Facilitar el acceso a recursos que posibiliten la autogesti?n. - Participar en la construcci?n de redes de apoyo mutuo, horizontales, asamblearias y generadas desde la base. - Publicar toda esta informaci?n en un formato atractivo para facilitar el acceso a toda la sociedad. Son 15 los d?as que restan para el pr?ximo 15 de marzo, d?a en el que ver? la luz ?Rebelaos!, publicaci?n por la autogesti?n. Hoy, hacemos p?blica la portada de ?Rebelaos! (versi?n en castellano) que pod?is visualizar en el siguiente enlace: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos El contenido de los titulares nos los guardamos para el 15 de marzo. ?Y t?? ?Te guardas el 15 de marzo? Adem?s, ya hemos superado los 200 nodos de distribuci?n, repartidos por todo el estado espa?ol. Ver el mapa: https://afinidadrebelde.crowdmap.com/ Por otro lado, la campa?a de financiaci?n contin?a avanzando y todav?a quedan 12 d?as para reunir los 6.000 euros que restan. Todas podemos aportar un poco para que todos los granitos de arena se conviertan en una gran playa el 15 de marzo. Pod?is acceder a la campa?a de cofinanciaci?n en: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Colectivo Afinidad Rebelde www.rebelaos.net From orquidea.peramor at gmail.com Fri Mar 2 19:29:14 2012 From: orquidea.peramor at gmail.com (Orquidea Salt mas) Date: Fri, 2 Mar 2012 20:29:14 +0100 Subject: [Pki-devel] =?iso-8859-1?q?Reb=E9late_by_self-management=2C_first?= =?iso-8859-1?q?_project_of_free_software_by_which_we_bet_all_/_Reb?= =?iso-8859-1?q?=E9late_por_la_autogesti=F3n=2C_primer_proyecto_de_?= =?iso-8859-1?q?software_libre_por_el_que_apostamos_todas?= Message-ID: Ingl?s : Many already we have contributed to the first project of free software dedicated to self-management in this campaign of collective financing, it collaborates and it spreads!/ Beginning campaign collective financing http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion?lang=en Login to enter with user of social networks and for would register in Goteo : http://www.goteo.org/user/login?lang=en Rebelaos! Publication by self-management A massive publication that floods the public transport, the work centers, the parks, the consumption centers, by means of distribution of 500,000 gratuitous units, acting simultaneously in all sides and nowhere. We announce the main tool of a vestibule Web for the management of self-sustaining resources by means of Drupal, in addition in the publication there will be an article dedicated to free software, hardware, It is being prepared in ingl?s, the machinery You can see more details in the index of the publication https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf . A computer system that allows us to share resources in all the scopes of our life so that we do not have to generate means different for each subject nor for each territory. A point of contact digitalis to generate projects of life outside Capitalism and to margin of the State. A tool to spread and to impel the social transformation through the resources that will set out in their contents around self-management, the autoorganizaci?n, the disobedience and the collective action. In which the capitalist system goes to the collapse, in a while immersed in a deep systemic crisis (ecological, political and economic, but mainly of values), where individual and collective of people they are being lacking of his fundamental rights, is necessary to develop a horizontal collective process where all the human beings we pruned to interact in equality of conditions and freedom. To interact means to relate to us (as much human as economically), to communicate to us, to cover our basic needs, to generate and to protect communal properties, to know and to provide collective solutions us problematic that our lives interfere. We want abrir a breach within normality in the monotonous life state-capitalist, a day anyone, that finally will not be any day. By means of this publication we try: - To drive a horizontal collective process where all and all we pruned to interact in equality of conditions and freedom. - To create communications network between the people it jeopardize with the change and arranged to act. - To find collective solutions to problematic that our lives interfere - To facilitate the access to resources that make possible self-management. - To participate in the construction of networks of mutual support, generated horizontals, asamblearias and from the base. - To publish all this information in an attractive format stops to facilitate the access to all the society. There are 15 days remaining for the upcoming March 15, the day that will come Rebelaos!, Magazine for the selfmanagement Today, we issue the cover of Rebelaos! (Castilian version) that can be displayed on the following link: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos The contents of the store owners to us by 15 March. Do you? Do you keep on 15 March? In addition, we have over 200 distribution nodes, distributed throughout the Spanish state. Check the map: https://afinidadrebelde.crowdmap.com/ On the other hand, the funding campaign continues to move and still have 12 days to collect the remaining 6,000 euros. We can all make a bit for all the grains of sand become a great beach on March 15. You can access the co-financing campaign: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Rebel Affinity group www.rebelaos.net ------------------------------------------------------------------------------- Castellano: Muchos ya hemos aportado al primer proyecto de software libre dedicado a la la financiaci?n colectiva, colabora y diffunde !!!!! Inicio campa?a financiaci?n colectiva goteo.org www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Link para registrarse en Goteo y acceder a redes sociales para colaborar en la difus?n http://www.goteo.org/user/login ?Rebelaos! Publicaci?n por la autogesti?n Una publicaci?n masiva que inunde el transporte p?blico, los centros de trabajo, los parques, los centros de consumo, mediante la distribuci?n de 500.000 ejemplares gratuitos, actuando simult?neamente en todos lados y en ninguna parte. Anunciamos la herramienta principal de un portal web para la gesti?n de recursos autogestionados mediante Drupal, adem?s en la publicaci?n habr? un art?culo dedicado al software libre, el hardware, la maquinaria... Puedes ver m?s detalles en el ?ndice de la publicaci?n https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf Un sistema inf?rmatico que nos permita compartir recursos en todos los ?mbitos de nuestra vida de forma que no tengamos que generar un medio distinto para cada tema ni para cada territorio. Un punto de encuentro digital para generar proyectos de vida fuera del capitalismo y al margen del Estado. Una herramienta para difundir e impulsar la transformaci?n social a trav?s de los recursos que se propondr?n en sus contenidos en torno a la autogesti?n, la autoorganizaci?n, la desobediencia y la acci?n colectiva. En un momento en que el sistema capitalista se dirige al colapso, inmerso en una profunda crisis sist?mica (ecol?gica, pol?tica y econ?mica, pero principalmente de valores), donde individuos y colectivos de personas est?n siendo desprovistos de sus derechos fundamentales, es necesario desarrollar un proceso colectivo horizontal donde todos los seres humanos podamos interactuar en igualdad de condiciones y en libertad. Interactuar significa relacionarnos (tanto humana como econ?micamente), comunicarnos, cubrir nuestras necesidades b?sicas, generar y proteger bienes comunes, conocernos y dar soluciones colectivas a problem?ticas que interfieren nuestras vidas. Queremos abrir una brecha dentro de la normalidad en la mon?tona vida estatal-capitalista, un d?a cualquiera, que finalmente no ser? cualquier d?a. Mediante esta publicaci?n pretendemos: - Impulsar un proceso colectivo horizontal donde todos y todas podamos interactuar en igualdad de condiciones y en libertad. - Crear red de comunicaciones entre las personas comprometidas con el cambio y dispuestas a actuar. - Encontrar soluciones colectivas a problem?ticas que interfieren nuestras vidas. - Facilitar el acceso a recursos que posibiliten la autogesti?n. - Participar en la construcci?n de redes de apoyo mutuo, horizontales, asamblearias y generadas desde la base. - Publicar toda esta informaci?n en un formato atractivo para facilitar el acceso a toda la sociedad. Son 15 los d?as que restan para el pr?ximo 15 de marzo, d?a en el que ver? la luz ?Rebelaos!, publicaci?n por la autogesti?n. Hoy, hacemos p?blica la portada de ?Rebelaos! (versi?n en castellano) que pod?is visualizar en el siguiente enlace: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos El contenido de los titulares nos los guardamos para el 15 de marzo. ?Y t?? ?Te guardas el 15 de marzo? Adem?s, ya hemos superado los 200 nodos de distribuci?n, repartidos por todo el estado espa?ol. Ver el mapa: https://afinidadrebelde.crowdmap.com/ Por otro lado, la campa?a de financiaci?n contin?a avanzando y todav?a quedan 12 d?as para reunir los 6.000 euros que restan. Todas podemos aportar un poco para que todos los granitos de arena se conviertan en una gran playa el 15 de marzo. Pod?is acceder a la campa?a de cofinanciaci?n en: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Colectivo Afinidad Rebelde www.rebelaos.net From edewata at redhat.com Fri Mar 2 20:51:40 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 02 Mar 2012 14:51:40 -0600 Subject: [Pki-devel] [PATCH] 28 Added CMSException. Message-ID: <4F5132DC.9010106@redhat.com> The CMSException was added to simplify error handling in REST services. The exception may include an error message and some other attributes. When the server throws a CMSException (or its subclass), the exception will be marshalled into XML and unmarshalled by the client, then thrown again as a new exception which can be caught by the application. Ticket #100 Note: This patch depends on patch #25-1. This patch also requires RESTEasy 2.3.2 jar files to be installed under /usr/share/java/resteasy. Might need to wait for ticket #29. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0028-Added-CMSException.patch Type: text/x-patch Size: 26914 bytes Desc: not available URL: From mharmsen at redhat.com Sat Mar 3 03:35:39 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 02 Mar 2012 19:35:39 -0800 Subject: [Pki-devel] [PATCH] Remove platform specific logic from patches for mock Message-ID: <4F51918B.3010202@redhat.com> The attached patch is for Dogtag 10 only. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-platform-specific-logic-from-patches-for-mock.patch Type: text/x-patch Size: 1972 bytes Desc: not available URL: From mharmsen at redhat.com Sat Mar 3 03:53:22 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 02 Mar 2012 19:53:22 -0800 Subject: [Pki-devel] [PATCH] Remove platform specific logic from patches for mock (Dogtag 9) Message-ID: <4F5195B2.8090108@redhat.com> The attached patch is for Dogtag 9 only. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-platform-specific-logic-from-patches-for-mock.patch Type: text/x-patch Size: 1850 bytes Desc: not available URL: From alee at redhat.com Mon Mar 5 03:34:10 2012 From: alee at redhat.com (Ade Lee) Date: Sun, 04 Mar 2012 22:34:10 -0500 Subject: [Pki-devel] [PATCH] 021 - Bug 769388 - pki-silent does not properly escape command-line arguments Message-ID: <1330918450.12061.2.camel@aleeredhat.laptop> Fixed the perl script that invokes pkisilent to escape special characters in the arguments. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0021-1-BZ-769388-pki-silent-does-not-properly-escape-comman.patch Type: text/x-patch Size: 1163 bytes Desc: not available URL: From mharmsen at redhat.com Mon Mar 5 06:15:30 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Sun, 04 Mar 2012 22:15:30 -0800 Subject: [Pki-devel] [PATCH] Associate PKI desktop icon with UI component (Dogtag 10) Message-ID: <4F545A02.6090304@redhat.com> The attached patch is for Dogtag 10 only. * Resolves *Bugzilla Bug #767800* - Firefox Launcher on Panel being modified for all users. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Associate-PKI-desktop-icon-with-UI-component.patch Type: text/x-patch Size: 33359 bytes Desc: not available URL: From mharmsen at redhat.com Mon Mar 5 06:17:16 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Sun, 04 Mar 2012 22:17:16 -0800 Subject: [Pki-devel] [PATCH] Associate PKI desktop icon with UI component (Dogtag 9) Message-ID: <4F545A6C.20009@redhat.com> The attached patch is for Dogtag 9 only. * Resolves *Bugzilla Bug #767800* - Firefox Launcher on Panel being modified for all users. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Associate-PKI-desktop-icon-with-UI-component.patch Type: text/x-patch Size: 33314 bytes Desc: not available URL: From mharmsen at redhat.com Mon Mar 5 06:27:54 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Sun, 04 Mar 2012 22:27:54 -0800 Subject: [Pki-devel] [PATCH] Associate PKI desktop icon with UI component (RHEL 6) Message-ID: <4F545CEA.8060602@redhat.com> The attached patch is for RHEL 6 only: * *Bugzilla Bug #745677* - Firefox Launcher on Panel being modified for all users. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Associate-PKI-desktop-icon-with-UI-component.patch Type: text/x-patch Size: 33306 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 5 20:38:26 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Mar 2012 14:38:26 -0600 Subject: [Pki-devel] Fwd: [PATCH] 25 Fixed DRM REST interface to use BigInteger. In-Reply-To: <4F4D2E10.7010502@redhat.com> References: <4F4D2E10.7010502@redhat.com> Message-ID: <4F552442.30701@redhat.com> Revised the patch to allow null ID as in the original code and to add Python test case for invalid ID. ACKed by Ade. Pushed to master. -------- Original Message -------- Subject: [PATCH] 25 Fixed DRM REST interface to use BigInteger. Date: Tue, 28 Feb 2012 13:42:08 -0600 From: Endi Sukma Dewata To: pki-devel at redhat.com The Key ID and request ID previously were Strings. They have been converted into BigIntegers. Ticket #94 Passed smoke test. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0025-2-Fixed-DRM-REST-interface-to-use-BigInteger.patch Type: text/x-patch Size: 56990 bytes Desc: not available URL: From mharmsen at redhat.com Mon Mar 5 21:07:38 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 05 Mar 2012 13:07:38 -0800 Subject: [Pki-devel] [PATCH] 021 - Bug 769388 - pki-silent does not properly escape command-line arguments In-Reply-To: <1330918450.12061.2.camel@aleeredhat.laptop> References: <1330918450.12061.2.camel@aleeredhat.laptop> Message-ID: <4F552B1A.3010906@redhat.com> On 03/04/12 19:34, Ade Lee wrote: > Fixed the perl script that invokes pkisilent to escape special > characters in the arguments. > > Please review. > Ade > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK -- I will port this change and add as a RHEL 6.3 patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Mon Mar 5 22:08:03 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 05 Mar 2012 17:08:03 -0500 Subject: [Pki-devel] [PATCH] 021 - Bug 769388 - pki-silent does not properly escape command-line arguments In-Reply-To: <4F552B1A.3010906@redhat.com> References: <1330918450.12061.2.camel@aleeredhat.laptop> <4F552B1A.3010906@redhat.com> Message-ID: <1330985284.12061.22.camel@aleeredhat.laptop> Pushed to master and dogtag 9. On Mon, 2012-03-05 at 13:07 -0800, Matthew Harmsen wrote: > On 03/04/12 19:34, Ade Lee wrote: > > Fixed the perl script that invokes pkisilent to escape special > > characters in the arguments. > > > > Please review. > > Ade > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > ACK -- I will port this change and add as a RHEL 6.3 patch From awnuk at redhat.com Tue Mar 6 00:57:09 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Mon, 05 Mar 2012 16:57:09 -0800 Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard Message-ID: <4F5560E5.6040903@redhat.com> Configuration wizard should provide option to issue ECC credentials for admin during ECC CA configuration. Bug #787806. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 787806.txt URL: From awnuk at redhat.com Tue Mar 6 01:05:18 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Mon, 05 Mar 2012 17:05:18 -0800 Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard (corrected attachment) Message-ID: <4F5562CE.7070703@redhat.com> Configuration wizard should provide option to issue ECC credentials for admin during ECC CA configuration. Bug #784387. (Please ignore previous attachment) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 784387.txt URL: From jmagne at redhat.com Tue Mar 6 01:12:10 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 05 Mar 2012 20:12:10 -0500 (EST) Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard (corrected attachment) In-Reply-To: <4F5562CE.7070703@redhat.com> Message-ID: <3d5a1d14-adff-4d20-b795-a81b97a8c462@zmail15.collab.prod.int.phx2.redhat.com> Was able to witness complete demo of the simple changes for this fix and it looked good. Changes here are very simple in letting the user select RSA or EC when requesting the admin certificate in the wizard. ACK, based on the requirement listed in the bug. ----- Original Message ----- From: "Andrew Wnuk" To: pki-devel at redhat.com Sent: Monday, March 5, 2012 5:05:18 PM Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard (corrected attachment) Configuration wizard should provide option to issue ECC credentials for admin during ECC CA configuration. Bug #784387. (Please ignore previous attachment) _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Tue Mar 6 02:22:29 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 05 Mar 2012 18:22:29 -0800 Subject: [Pki-devel] [PATCHES] Removal of PKI desktop icons . . . Message-ID: <4F5574E5.9030009@redhat.com> The following patches are for the RHEL 6 PKI GIT branch entitled "IPA_v2_RHEL_6_ERRATA_BRANCH" and resolve the following bug: * *Bugzilla Bug #745677* -Firefox Launcher on Panel being modified for all users. The first attached patch removes the desktop icon for CA subsystems and removes all desktop icon logic from pkicreate. The second attached patch removes the desktop icons from all other PKI subsystems. The third attached patch applies the CA desktop icon removal patch and updates the 'pki-core' spec file to utilize this patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0026-BZ-745677-Remove-CA-desktop-icon.patch Type: text/x-patch Size: 5160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-all-other-PKI-desktop-icons.patch Type: text/x-patch Size: 11849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Apply-patch-to-remove-CA-desktop-icon.patch Type: text/x-patch Size: 6060 bytes Desc: not available URL: From jmagne at redhat.com Tue Mar 6 02:47:35 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 05 Mar 2012 21:47:35 -0500 (EST) Subject: [Pki-devel] [PATCHES] Removal of PKI desktop icons . . . In-Reply-To: <4F5574E5.9030009@redhat.com> Message-ID: <9b5aca66-edf7-47d9-9925-9cad44dbcd43@zmail15.collab.prod.int.phx2.redhat.com> Viewed a quick demo of the functionality in action. There are no further mentions of the desktop config file in amy of the setup logs. Also the desktop file itself is not showing up where it previously had. After looking at the simple changes in the patches. ACK, for all three. ----- Original Message ----- From: "Matthew Harmsen" To: pki-devel at redhat.com Sent: Monday, March 5, 2012 6:22:29 PM Subject: [Pki-devel] [PATCHES] Removal of PKI desktop icons . . . The following patches are for the RHEL 6 PKI GIT branch entitled "IPA_v2_RHEL_6_ERRATA_BRANCH" and resolve the following bug: ? Bugzilla Bug #745677 - Firefox Launcher on Panel being modified for all users. The first attached patch removes the desktop icon for CA subsystems and removes all desktop icon logic from pkicreate. The second attached patch removes the desktop icons from all other PKI subsystems. The third attached patch applies the CA desktop icon removal patch and updates the 'pki-core' spec file to utilize this patch. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Tue Mar 6 04:52:55 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 05 Mar 2012 20:52:55 -0800 Subject: [Pki-devel] Request to build pki-core-9.0.3-23.el6 for RHEL 6.3 in Brew . . . Message-ID: <4F559827.908@redhat.com> We would like to request an official build of 'pki-core-9.0.3-23.el6' for RHEL 6.3 in Brew to resolve the following bugs: * *Bugzilla Bug #745677* -Firefox Launcher on Panel being modified for all users. * *Bugzilla Bug #769388* -pki-silent does not properly escape command-line arguments The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * 0025-BZ-771790-sslget-does-not-work-after-FEDORA-2011-174.patch * 0026-BZ-745677-Remove-CA-desktop-icon.patch * 0027-BZ-769388-pki-silent-does-not-properly-escape-command-line-arguments.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 44539 bytes Desc: not available URL: From release-engineering at redhat.com Tue Mar 6 04:53:03 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Mon, 5 Mar 2012 23:53:03 -0500 Subject: [Pki-devel] [engineering.redhat.com #144866] Request to build pki-core-9.0.3-23.el6 for RHEL 6.3 in Brew . . . In-Reply-To: <4F559827.908@redhat.com> References: <4F559827.908@redhat.com> Message-ID: Ticket We would like to request an official build of 'pki-core-9.0.3-23.el6' for RHEL 6.3 in Brew to resolve the following bugs: * *Bugzilla Bug #745677* -Firefox Launcher on Panel being modified for all users. * *Bugzilla Bug #769388* -pki-silent does not properly escape command-line arguments The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * 0025-BZ-771790-sslget-does-not-work-after-FEDORA-2011-174.patch * 0026-BZ-745677-Remove-CA-desktop-icon.patch * 0027-BZ-769388-pki-silent-does-not-properly-escape-command-line-arguments.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 44539 bytes Desc: not available URL: From release-engineering at redhat.com Tue Mar 6 06:27:45 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Tue, 6 Mar 2012 01:27:45 -0500 Subject: [Pki-devel] [engineering.redhat.com #144866] Request to build pki-core-9.0.3-23.el6 for RHEL 6.3 in Brew . . . In-Reply-To: <4F559827.908@redhat.com> References: <4F559827.908@redhat.com> Message-ID: Ticket done: Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4117392 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=201705 From awnuk at redhat.com Tue Mar 6 18:43:04 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 06 Mar 2012 10:43:04 -0800 Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard (corrected attachment) In-Reply-To: <3d5a1d14-adff-4d20-b795-a81b97a8c462@zmail15.collab.prod.int.phx2.redhat.com> References: <3d5a1d14-adff-4d20-b795-a81b97a8c462@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F565AB8.2090807@redhat.com> On 03/05/2012 05:12 PM, John Magne wrote: > > Was able to witness complete demo of the simple changes for this fix and it looked good. > > Changes here are very simple in letting the user select RSA or EC when requesting the admin certificate > in the wizard. > > ACK, based on the requirement listed in the bug. > > ----- Original Message ----- > From: "Andrew Wnuk" > To: pki-devel at redhat.com > Sent: Monday, March 5, 2012 5:05:18 PM > Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard (corrected attachment) > > Configuration wizard should provide option to issue ECC credentials for > admin during ECC CA configuration. > > Bug #784387. > > (Please ignore previous attachment) > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Pushed to DOGTAG_9_BRANCH. From awnuk at redhat.com Tue Mar 6 19:12:53 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 06 Mar 2012 11:12:53 -0800 Subject: [Pki-devel] Option to create ECC credentials for admin from configuration wizard (corrected attachment) In-Reply-To: <4F565AB8.2090807@redhat.com> References: <3d5a1d14-adff-4d20-b795-a81b97a8c462@zmail15.collab.prod.int.phx2.redhat.com> <4F565AB8.2090807@redhat.com> Message-ID: <4F5661B5.9060306@redhat.com> On 03/06/2012 10:43 AM, Andrew Wnuk wrote: > On 03/05/2012 05:12 PM, John Magne wrote: >> >> Was able to witness complete demo of the simple changes for this fix >> and it looked good. >> >> Changes here are very simple in letting the user select RSA or EC >> when requesting the admin certificate >> in the wizard. >> >> ACK, based on the requirement listed in the bug. >> >> ----- Original Message ----- >> From: "Andrew Wnuk" >> To: pki-devel at redhat.com >> Sent: Monday, March 5, 2012 5:05:18 PM >> Subject: [Pki-devel] Option to create ECC credentials for admin from >> configuration wizard (corrected attachment) >> >> Configuration wizard should provide option to issue ECC credentials for >> admin during ECC CA configuration. >> >> Bug #784387. >> >> (Please ignore previous attachment) >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > Pushed to DOGTAG_9_BRANCH. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Pushed to master. From mharmsen at redhat.com Tue Mar 6 22:29:34 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 06 Mar 2012 14:29:34 -0800 Subject: [Pki-devel] [PATCH] Remove PKI desktop icons (Dogtag 9) Message-ID: <4F568FCE.5030309@redhat.com> The attached patch resolves the following bug on Dogtag 9 only: * *Bugzilla Bug #767800* -Firefox Launcher on Panel being modified for all users. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-PKI-desktop-icons.patch Type: text/x-patch Size: 16661 bytes Desc: not available URL: From mharmsen at redhat.com Tue Mar 6 22:29:36 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 06 Mar 2012 14:29:36 -0800 Subject: [Pki-devel] [PATCH] Remove PKI desktop icons (Dogtag 10) Message-ID: <4F568FD0.9040403@redhat.com> The attached patch resolves the following bug on Dogtag 10 only: * *Bugzilla Bug #767800* -Firefox Launcher on Panel being modified for all users. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-PKI-desktop-icons.patch Type: text/x-patch Size: 16703 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 7 19:35:02 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Mar 2012 13:35:02 -0600 Subject: [Pki-devel] [PATCH] 29 Replaced daemon threads with executor service. Message-ID: <4F57B866.8030902@redhat.com> The certificate status update and retrieving modifications tasks have been modified to use the executor service. Unlike daemon threads, the service will allow existing task to exit gracefully before shutting down. An abandon operation is used terminate the persistent search used for retrieving modifications. Some methods have been moved to CertificateRepository class to simplify synchronizations. Ticket #73 This patch should be applied on top of #26 (or they can be squashed). There are some other threads that can be converted to use executor service as well, it will be done in separate patches. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0029-Replaced-daemon-threads-with-executor-service.patch Type: text/x-patch Size: 23258 bytes Desc: not available URL: From alee at redhat.com Thu Mar 8 03:50:41 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 07 Mar 2012 22:50:41 -0500 Subject: [Pki-devel] [PATCH] 0022 - Fixes to cloning and security domain for client auth access to db Message-ID: <1331178641.12061.31.camel@aleeredhat.laptop> Please review: Fixes to cloning and security domain tables for client auth internaldb user The mechanism for getting an ldap connection to the internaldb was incorrect, both in the Security Domain Session Table and the DatabasePanel. As a result, connections to the internaldb failed for accessing the security domain session table and when trying to clone a master which connects to its database using client auth. The thread that handles reading the security domain session table is now only instantiated when running on a configured security domain master. Additionally, needed acls for the client auth certificate ldap user have been moved to manager.ldif. This includes acls to allow creation and management of replication agreements and replication users (now being created under ou=csusers, cn=config) Ticket #5 -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0022-Fixes-to-cloning-and-security-domain-tables-for-clie.patch Type: text/x-patch Size: 49241 bytes Desc: not available URL: From alee at redhat.com Thu Mar 8 04:35:08 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 07 Mar 2012 23:35:08 -0500 Subject: [Pki-devel] [PATCH] 23 Fixed IAttrSet.getElements() implementations. In-Reply-To: <4F47F5A5.9090307@redhat.com> References: <4F47F5A5.9090307@redhat.com> Message-ID: <1331181309.12061.44.camel@aleeredhat.laptop> Endi, I was at first a little leery of the changes in getElement() in AuthCredentials.java and EmailResolverKeys.java. While the change seems to make sense from looking at the class, it was not clear why the methods had been working this far with no issues. But, it seems to me -- and you should confirm this -- that these methods are currently unused and therefore we can change them with no problems. Please confirm that they are not called - not only in Java but also Javascript code. There are a couple of files in the patch where the only change appears to be adding a line at the end of the file. Is that intentional and/or needed? (LdapPredicateParser, PolicyPredicateParser). In Main.java in 71ToText, there appears to be an error - with a duplicate assignment taking place. Ade On Fri, 2012-02-24 at 14:40 -0600, Endi Sukma Dewata wrote: > This patch fixes incorrect implementation of getElement() in > some subclasses of IAttrSet. The method is supposed return the > attribute names as an enumeration of strings. > > Ticket #42 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Mar 8 15:14:41 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 08 Mar 2012 10:14:41 -0500 Subject: [Pki-devel] [PATCH] 24 Refactored NameValuePairs. In-Reply-To: <4F4BCAAF.2050003@redhat.com> References: <4F4BCAAF.2050003@redhat.com> Message-ID: <1331219682.12061.49.camel@aleeredhat.laptop> Whew! That was a long review .. lots of files changed. I was starting to see a bunch of formatting errors in the console code, only to realize that the console code somehow missed reformatting. So, after the checkins are done, its worth doing a reformat of the console code. I will run that and submit as a separate patch. Please make sure you check things out on the console to confirm they look OK. Is so, ACK. Ade On Mon, 2012-02-27 at 12:25 -0600, Endi Sukma Dewata wrote: > The NameValuePairs class has been modified to extend the Linked- > HashMap which preserves the order of elements as in the original > code. Some methods are renamed to match Java Map interface. The > NameValuePair class is no longer needed and has been removed. > > Ticket #78 > > http://fedorapeople.org/gitweb?p=edewata/public_git/pki.git;a=commitdiff;h=e7c603e871bca4345f2da73e39de6ffd786ffc13 > > Passed smoke test. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Fri Mar 9 02:53:08 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 08 Mar 2012 18:53:08 -0800 Subject: [Pki-devel] [PATCH] PKI Deployment Framework Message-ID: <4F597094.1030709@redhat.com> The attached patch was revised to be applied and built against the current "master". It attempts to present an initial attempt to implement the design for the python-based PKI installer described in 'http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment'. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PKI-Deployment-Framework.patch Type: text/x-patch Size: 72747 bytes Desc: not available URL: From alee at redhat.com Fri Mar 9 07:34:55 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 09 Mar 2012 02:34:55 -0500 Subject: [Pki-devel] [PATCH] 0022 - Fixes to cloning and security domain for client auth access to db In-Reply-To: <1331178641.12061.31.camel@aleeredhat.laptop> References: <1331178641.12061.31.camel@aleeredhat.laptop> Message-ID: <1331278496.20827.2.camel@aleeredhat.laptop> Addressed a couple of issues found by Endi. 1. master ldap password needed to be stored and removed temporarily. 2. added error logs for ldif imports. Acked by Endi. Pushed to dogtag 9 and master (dogtag 10). Ade On Wed, 2012-03-07 at 22:50 -0500, Ade Lee wrote: > Please review: > > Fixes to cloning and security domain tables for client auth internaldb user > > The mechanism for getting an ldap connection to the internaldb was incorrect, > both in the Security Domain Session Table and the DatabasePanel. As a result, > connections to the internaldb failed for accessing the security domain session > table and when trying to clone a master which connects to its database using > client auth. > > The thread that handles reading the security domain session table is now only > instantiated when running on a configured security domain master. > > Additionally, needed acls for the client auth certificate ldap user have been > moved to manager.ldif. This includes acls to allow creation and management of > replication agreements and replication users (now being created under > ou=csusers, cn=config) > > Ticket #5 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Mar 9 16:50:25 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 09 Mar 2012 11:50:25 -0500 Subject: [Pki-devel] [PATCH] 29 Replaced daemon threads with executor service. In-Reply-To: <4F57B866.8030902@redhat.com> References: <4F57B866.8030902@redhat.com> Message-ID: <1331311826.20827.5.camel@aleeredhat.laptop> ACK on 26 and 29. On Wed, 2012-03-07 at 13:35 -0600, Endi Sukma Dewata wrote: > The certificate status update and retrieving modifications tasks > have been modified to use the executor service. Unlike daemon > threads, the service will allow existing task to exit gracefully > before shutting down. An abandon operation is used terminate the > persistent search used for retrieving modifications. Some methods > have been moved to CertificateRepository class to simplify > synchronizations. > > Ticket #73 > > This patch should be applied on top of #26 (or they can be squashed). > There are some other threads that can be converted to use executor > service as well, it will be done in separate patches. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Mar 9 19:24:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Mar 2012 13:24:56 -0600 Subject: [Pki-devel] Resteasy Message-ID: <4F5A5908.6000003@redhat.com> Ade, The resteasy package depends the following packages to build: * glassfish-fastinfoset instead of glassfish-fi * jboss-annotations-1.1-api After fixing the dependencies, it failed to build due to some test errors. See attachment. There are a bunch of these messages: MIME map can't be loaded:java.lang.NullPointerException -- Endi S. Dewata -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: resteasy.txt URL: From jmagne at redhat.com Sat Mar 10 03:19:29 2012 From: jmagne at redhat.com (John Magne) Date: Fri, 09 Mar 2012 22:19:29 -0500 (EST) Subject: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch In-Reply-To: <82e6f56b-fdf9-4203-8603-85461f42eed8@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <26ea132f-f7d7-4e84-83c8-55047cd2d1a9@zmail15.collab.prod.int.phx2.redhat.com> Patch to provide a custom tomcat Realm to protect CS servlets with both client authentication protection and simple authorization protection. Testing instructions in the patch's checkin message. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Provide-Custom-PKI-JNDI-Realm.patch Type: text/x-patch Size: 72727 bytes Desc: not available URL: From mharmsen at redhat.com Sat Mar 10 04:10:10 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 09 Mar 2012 20:10:10 -0800 Subject: [Pki-devel] [PATCH] Get DOGTAG_9_BRANCH GIT repository in-sync with SVN namesake Message-ID: <4F5AD422.1040805@redhat.com> This patch is for Dogtag 9 ONLY, and resolves the following bug: * *Bugzilla Bug #796006* -Get DOGTAG_9_BRANCH GIT repository in-sync with DOGTAG_9_BRANCH SVN repository . . . The spec files have been altered within this patch so that the following new Dogtag 9 packages can be constructed: * dogtag-pki-theme-9.0.11-1 * dogtag-pki-9.0.0-10 * pki-core-9.0.18-1 * pki-kra-9.0.10-1 * pki-ocsp-9.0.9-1 * pki-tks-9.0.9-1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Get-DOGTAG_9_BRANCH-GIT-repository-in-sync-with-SVN-namesake.patch Type: text/x-patch Size: 21131 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 12 14:43:40 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Mar 2012 09:43:40 -0500 Subject: [Pki-devel] [PATCH] 26 Refactored JobsScheduler. In-Reply-To: <4F4D640D.4080907@redhat.com> References: <4F4D640D.4080907@redhat.com> Message-ID: <4F5E0B9C.2000902@redhat.com> On 2/28/2012 5:32 PM, Endi Sukma Dewata wrote: > The JobsScheduler has been modified to stop all jobs on shutdown. > This is done by setting a flag in each job instead of stopping the > job thread abruptly. Long running jobs should check this flag > periodically and then exit gracefully. None of the existing jobs > need to do this since they do not run very long. > > Other threads that run background services have been converted into > daemons such that they will terminate automatically when the JVM > exits. > > Ticket #73 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Mar 12 14:43:50 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Mar 2012 09:43:50 -0500 Subject: [Pki-devel] [PATCH] 29 Replaced daemon threads with executor service. In-Reply-To: <1331311826.20827.5.camel@aleeredhat.laptop> References: <4F57B866.8030902@redhat.com> <1331311826.20827.5.camel@aleeredhat.laptop> Message-ID: <4F5E0BA6.7000604@redhat.com> On 3/9/2012 10:50 AM, Ade Lee wrote: > ACK on 26 and 29. Pushed to master. Thanks. > On Wed, 2012-03-07 at 13:35 -0600, Endi Sukma Dewata wrote: >> The certificate status update and retrieving modifications tasks >> have been modified to use the executor service. Unlike daemon >> threads, the service will allow existing task to exit gracefully >> before shutting down. An abandon operation is used terminate the >> persistent search used for retrieving modifications. Some methods >> have been moved to CertificateRepository class to simplify >> synchronizations. >> >> Ticket #73 >> >> This patch should be applied on top of #26 (or they can be squashed). >> There are some other threads that can be converted to use executor >> service as well, it will be done in separate patches. -- Endi S. Dewata From edewata at redhat.com Mon Mar 12 17:45:54 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Mar 2012 12:45:54 -0500 Subject: [Pki-devel] [PATCH] 24 Refactored NameValuePairs. In-Reply-To: <1331219682.12061.49.camel@aleeredhat.laptop> References: <4F4BCAAF.2050003@redhat.com> <1331219682.12061.49.camel@aleeredhat.laptop> Message-ID: <4F5E3652.6060006@redhat.com> On 3/8/2012 9:14 AM, Ade Lee wrote: > Whew! That was a long review .. lots of files changed. > > I was starting to see a bunch of formatting errors in the console code, > only to realize that the console code somehow missed reformatting. So, > after the checkins are done, its worth doing a reformat of the console > code. I will run that and submit as a separate patch. > > Please make sure you check things out on the console to confirm they > look OK. Is so, ACK. Everything looks OK in console. Pushed to master. Thanks. > On Mon, 2012-02-27 at 12:25 -0600, Endi Sukma Dewata wrote: >> The NameValuePairs class has been modified to extend the Linked- >> HashMap which preserves the order of elements as in the original >> code. Some methods are renamed to match Java Map interface. The >> NameValuePair class is no longer needed and has been removed. >> >> Ticket #78 >> >> http://fedorapeople.org/gitweb?p=edewata/public_git/pki.git;a=commitdiff;h=e7c603e871bca4345f2da73e39de6ffd786ffc13 >> >> Passed smoke test. -- Endi S. Dewata From edewata at redhat.com Mon Mar 12 20:45:52 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Mar 2012 15:45:52 -0500 Subject: [Pki-devel] [PATCH] 23 Fixed IAttrSet.getElements() implementations. In-Reply-To: <1331181309.12061.44.camel@aleeredhat.laptop> References: <4F47F5A5.9090307@redhat.com> <1331181309.12061.44.camel@aleeredhat.laptop> Message-ID: <4F5E6080.6090803@redhat.com> New patch attached. On 3/7/2012 10:35 PM, Ade Lee wrote: > I was at first a little leery of the changes in getElement() in > AuthCredentials.java and EmailResolverKeys.java. While the change seems > to make sense from looking at the class, it was not clear why the > methods had been working this far with no issues. But, it seems to me > -- and you should confirm this -- that these methods are currently > unused and therefore we can change them with no problems. > > Please confirm that they are not called - not only in Java but also > Javascript code. Yes, I couldn't find any references to the getElements() method that uses the above classes. > There are a couple of files in the patch where the only change appears > to be adding a line at the end of the file. Is that intentional and/or > needed? (LdapPredicateParser, PolicyPredicateParser). Actually the patch removes unused AttributeSet class from those files. I've revised the patch to remove unused imports too. > In Main.java in 71ToText, there appears to be an error - with a > duplicate assignment taking place. This is fixed now. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-edewata-0023-1-Fixed-IAttrSet.getElements-implementations.patch Type: text/x-patch Size: 18606 bytes Desc: not available URL: From alee at redhat.com Mon Mar 12 21:47:17 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 12 Mar 2012 17:47:17 -0400 Subject: [Pki-devel] [PATCH] 23 Fixed IAttrSet.getElements() implementations. In-Reply-To: <4F5E6080.6090803@redhat.com> References: <4F47F5A5.9090307@redhat.com> <1331181309.12061.44.camel@aleeredhat.laptop> <4F5E6080.6090803@redhat.com> Message-ID: <1331588839.818.12.camel@aleeredhat.laptop> ack On Mon, 2012-03-12 at 15:45 -0500, Endi Sukma Dewata wrote: > New patch attached. > > On 3/7/2012 10:35 PM, Ade Lee wrote: > > I was at first a little leery of the changes in getElement() in > > AuthCredentials.java and EmailResolverKeys.java. While the change seems > > to make sense from looking at the class, it was not clear why the > > methods had been working this far with no issues. But, it seems to me > > -- and you should confirm this -- that these methods are currently > > unused and therefore we can change them with no problems. > > > > Please confirm that they are not called - not only in Java but also > > Javascript code. > > Yes, I couldn't find any references to the getElements() method that > uses the above classes. > > > There are a couple of files in the patch where the only change appears > > to be adding a line at the end of the file. Is that intentional and/or > > needed? (LdapPredicateParser, PolicyPredicateParser). > > Actually the patch removes unused AttributeSet class from those files. > I've revised the patch to remove unused imports too. > > > In Main.java in 71ToText, there appears to be an error - with a > > duplicate assignment taking place. > > This is fixed now. > From jmagne at redhat.com Mon Mar 12 22:11:14 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 12 Mar 2012 18:11:14 -0400 (EDT) Subject: [Pki-devel] [PATCH] Get DOGTAG_9_BRANCH GIT repository in-sync with SVN namesake In-Reply-To: <4F5AD422.1040805@redhat.com> Message-ID: Simple changes to merge a handful of bugs into Dogtag 9. Consisting of a few pre-reviewed code fixes and some changes to cmake build content and various spec files. Looks good: ACK ----- Original Message ----- From: "Matthew Harmsen" To: pki-devel at redhat.com Sent: Friday, March 9, 2012 8:10:10 PM Subject: [Pki-devel] [PATCH] Get DOGTAG_9_BRANCH GIT repository in-sync with SVN namesake This patch is for Dogtag 9 ONLY, and resolves the following bug: ? Bugzilla Bug #796006 - Get DOGTAG_9_BRANCH GIT repository in-sync with DOGTAG_9_BRANCH SVN repository . . . The spec files have been altered within this patch so that the following new Dogtag 9 packages can be constructed: ? dogtag-pki-theme-9.0.11-1 ? dogtag-pki-9.0.0-10 ? pki-core-9.0.18-1 ? pki-kra-9.0.10-1 ? pki-ocsp-9.0.9-1 ? pki-tks-9.0.9-1 _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Mon Mar 12 23:37:55 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 12 Mar 2012 16:37:55 -0700 Subject: [Pki-devel] Request to build the following PKI components on Fedora 15, Fedora 16, Fedora 17, and Fedora 18 (Rawhide) . . . Message-ID: <4F5E88D3.8010108@redhat.com> Fixes have been made to address the following bugs: * *Bugzilla Bug #796006* -Get DOGTAG_9_BRANCH GIT repository in-sync with DOGTAG_9_BRANCH SVN repository . . . * *Bugzilla Bug #747381* -After the migration (7.1->8.1) CA agent page displays admin cert request with authtime attribute twice * *Bugzilla Bug #747019* -Migrated policy requests from 7.1->8.1 displays issuedcerts and cert_Info params as base 64 blobs. * *Bugzilla Bug #757848* -DRM re-key tool: introduces a blank line in the middle of an ldif entry. * *Bugzilla Bug #801840* -pki_silent.template missing opening brace on line 1314 for ca_external variable Please build the following components on Fedora 15, Fedora 16, Fedora 17, and Fedora 18 (rawhide) in Koji . . . * dogtag-pki-theme-9.0.11-1.fc[15,16,17,18].src.rpm (dogtag-pki-theme) * pki-core-9.0.18-1.fc[15,16,17,18].src.rpm (pki-core) * pki-kra-9.0.10-1.fc[15,16,17,18].src.rpm (pki-kra) * pki-ocsp-9.0.9-1.fc[15,16,17,18].src.rpm (pki-ocsp) * pki-tks-9.0.9-1.fc[15,16,17,18].src.rpm (pki-tks) * dogtag-pki-9.0.0-10.fc[15,16,17,18].src.rpm (dogtag-pki - contains NO source tarball as this is a meta-package) All changes have been checked-in, and the official tarballs (for all three platforms) have been published to: * http://pki.fedoraproject.org/pki/sources/dogtag-pki-theme/dogtag-pki-theme-9.0.11.tar.gz (dogtag-pki-theme) * http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.18.tar.gz (pki-core) * http://pki.fedoraproject.org/pki/sources/pki-kra/pki-kra-9.0.10.tar.gz (pki-kra) * http://pki.fedoraproject.org/pki/sources/pki-ocsp/pki-ocsp-9.0.9.tar.gz (pki-ocsp) * http://pki.fedoraproject.org/pki/sources/pki-tks/pki-tks-9.0.9.tar.gz (pki-tks) The official spec files (for all three platforms) are located at: * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dogtag-pki-theme.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-core.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-kra.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-ocsp.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-tks.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dogtag-pki.spec Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From release-engineering at redhat.com Mon Mar 12 23:38:03 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Mon, 12 Mar 2012 19:38:03 -0400 Subject: [Pki-devel] [engineering.redhat.com #145654] Request to build the following PKI components on Fedora 15, Fedora 16, Fedora 17, and Fedora 18 (Rawhide) . . . In-Reply-To: <4F5E88D3.8010108@redhat.com> References: <4F5E88D3.8010108@redhat.com> Message-ID: Ticket Fixes have been made to address the following bugs: * *Bugzilla Bug #796006* -Get DOGTAG_9_BRANCH GIT repository in-sync with DOGTAG_9_BRANCH SVN repository . . . * *Bugzilla Bug #747381* -After the migration (7.1->8.1) CA agent page displays admin cert request with authtime attribute twice * *Bugzilla Bug #747019* -Migrated policy requests from 7.1->8.1 displays issuedcerts and cert_Info params as base 64 blobs. * *Bugzilla Bug #757848* -DRM re-key tool: introduces a blank line in the middle of an ldif entry. * *Bugzilla Bug #801840* -pki_silent.template missing opening brace on line 1314 for ca_external variable Please build the following components on Fedora 15, Fedora 16, Fedora 17, and Fedora 18 (rawhide) in Koji . . . * dogtag-pki-theme-9.0.11-1.fc[15,16,17,18].src.rpm (dogtag-pki-theme) * pki-core-9.0.18-1.fc[15,16,17,18].src.rpm (pki-core) * pki-kra-9.0.10-1.fc[15,16,17,18].src.rpm (pki-kra) * pki-ocsp-9.0.9-1.fc[15,16,17,18].src.rpm (pki-ocsp) * pki-tks-9.0.9-1.fc[15,16,17,18].src.rpm (pki-tks) * dogtag-pki-9.0.0-10.fc[15,16,17,18].src.rpm (dogtag-pki - contains NO source tarball as this is a meta-package) All changes have been checked-in, and the official tarballs (for all three platforms) have been published to: * http://pki.fedoraproject.org/pki/sources/dogtag-pki-theme/dogtag-pki-theme-9.0.11.tar.gz (dogtag-pki-theme) * http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.18.tar.gz (pki-core) * http://pki.fedoraproject.org/pki/sources/pki-kra/pki-kra-9.0.10.tar.gz (pki-kra) * http://pki.fedoraproject.org/pki/sources/pki-ocsp/pki-ocsp-9.0.9.tar.gz (pki-ocsp) * http://pki.fedoraproject.org/pki/sources/pki-tks/pki-tks-9.0.9.tar.gz (pki-tks) The official spec files (for all three platforms) are located at: * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dogtag-pki-theme.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-core.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-kra.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-ocsp.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki-tks.spec * http://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dogtag-pki.spec Thanks, -- Matt From jmagne at redhat.com Tue Mar 13 00:31:48 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 12 Mar 2012 20:31:48 -0400 (EDT) Subject: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch In-Reply-To: <26ea132f-f7d7-4e84-83c8-55047cd2d1a9@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <6d361f89-0ec0-4ae3-b1f8-ecb58380eee8@zmail15.collab.prod.int.phx2.redhat.com> Based on ACK from alee, along with suggested minor changes. Pushed to master. ----- Original Message ----- From: "John Magne" To: pki-devel at redhat.com Sent: Friday, March 9, 2012 7:19:29 PM Subject: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch Patch to provide a custom tomcat Realm to protect CS servlets with both client authentication protection and simple authorization protection. Testing instructions in the patch's checkin message. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From release-engineering at redhat.com Tue Mar 13 03:38:28 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Mon, 12 Mar 2012 23:38:28 -0400 Subject: [Pki-devel] [engineering.redhat.com #145654] Request to build the following PKI components on Fedora 15, Fedora 16, Fedora 17, and Fedora 18 (Rawhide) . . . In-Reply-To: <4F5E88D3.8010108@redhat.com> References: <4F5E88D3.8010108@redhat.com> Message-ID: Ticket all builds complete and submitted to bodhi. From ayoung at redhat.com Tue Mar 13 14:33:20 2012 From: ayoung at redhat.com (Adam Young) Date: Tue, 13 Mar 2012 10:33:20 -0400 Subject: [Pki-devel] [PATCH] 48-Removed-CMakeLists-from-build-path-to-avoid-spurious-warnings Message-ID: <4F5F5AB0.5080404@redhat.com> Trivial patch, but removes 3 warnings in the overall count. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-admiyo-0061-Remove-unused-variable-and-import.patch Type: text/x-patch Size: 2153 bytes Desc: not available URL: From alee at redhat.com Tue Mar 13 14:39:41 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 13 Mar 2012 10:39:41 -0400 Subject: [Pki-devel] [PATCH] 48-Removed-CMakeLists-from-build-path-to-avoid-spurious-warnings In-Reply-To: <4F5F5AB0.5080404@redhat.com> References: <4F5F5AB0.5080404@redhat.com> Message-ID: <1331649582.818.17.camel@aleeredhat.laptop> ack On Tue, 2012-03-13 at 10:33 -0400, Adam Young wrote: > Trivial patch, but removes 3 warnings in the overall count. > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Mar 13 16:01:30 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 13 Mar 2012 11:01:30 -0500 Subject: [Pki-devel] [PATCH] 23 Fixed IAttrSet.getElements() implementations. In-Reply-To: <1331588839.818.12.camel@aleeredhat.laptop> References: <4F47F5A5.9090307@redhat.com> <1331181309.12061.44.camel@aleeredhat.laptop> <4F5E6080.6090803@redhat.com> <1331588839.818.12.camel@aleeredhat.laptop> Message-ID: <4F5F6F5A.7030109@redhat.com> On 3/12/2012 4:47 PM, Ade Lee wrote: > ack Pushed to master. -- Endi S. Dewata From ayoung at redhat.com Tue Mar 13 16:07:14 2012 From: ayoung at redhat.com (Adam Young) Date: Tue, 13 Mar 2012 12:07:14 -0400 Subject: [Pki-devel] [PATCH] 48-Removed-CMakeLists-from-build-path-to-avoid-spurious-warnings In-Reply-To: <4F5F5AB0.5080404@redhat.com> References: <4F5F5AB0.5080404@redhat.com> Message-ID: <4F5F70B2.7040907@redhat.com> On 03/13/2012 10:33 AM, Adam Young wrote: > Trivial patch, but removes 3 warnings in the overall count. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Correct patch attached -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dogtag-admiyo-0048-Removed-CMakeLists-from-build-path-to-avoid-spurious.patch Type: text/x-patch Size: 1305 bytes Desc: not available URL: From edewata at redhat.com Tue Mar 13 16:46:19 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 13 Mar 2012 11:46:19 -0500 Subject: [Pki-devel] [PATCH] 48-Removed-CMakeLists-from-build-path-to-avoid-spurious-warnings In-Reply-To: <4F5F70B2.7040907@redhat.com> References: <4F5F5AB0.5080404@redhat.com> <4F5F70B2.7040907@redhat.com> Message-ID: <4F5F79DB.1020908@redhat.com> On 3/13/2012 11:07 AM, Adam Young wrote: > On 03/13/2012 10:33 AM, Adam Young wrote: >> Trivial patch, but removes 3 warnings in the overall count. >> > Correct patch attached ACK. Pushed to master. -- Endi S. Dewata From ayoung at redhat.com Wed Mar 14 01:45:46 2012 From: ayoung at redhat.com (Adam Young) Date: Tue, 13 Mar 2012 21:45:46 -0400 Subject: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch In-Reply-To: <26ea132f-f7d7-4e84-83c8-55047cd2d1a9@zmail15.collab.prod.int.phx2.redhat.com> References: <26ea132f-f7d7-4e84-83c8-55047cd2d1a9@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F5FF84A.1040701@redhat.com> On 03/09/2012 10:19 PM, John Magne wrote: > Patch to provide a custom tomcat Realm to protect CS servlets with > both client authentication protection and simple authorization protection. > > Testing instructions in the patch's checkin message. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Sorry I missed this. This is really cool. Would you say that this is a complete solution for the Authentication piece (Modulo maybe extending the ACIs) or is there more work to be done. Am I correct in understanding that this uses ACIs for Authorization? -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Mar 14 18:09:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Mar 2012 13:09:23 -0500 Subject: [Pki-devel] [PATCH] 30 Escape parameter values in search filter. Message-ID: <4F60DED3.6050006@redhat.com> The REST interface was vulnerable to injection attack. This has been fixed by escaping the special characters in parameter values before using them in the search filter. Ticket #96 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0030-Escape-parameter-values-in-search-filter.patch Type: text/x-patch Size: 4824 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 14 19:48:06 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Mar 2012 14:48:06 -0500 Subject: [Pki-devel] [PATCH] 30 Escape parameter values in search filter. In-Reply-To: <4F60DED3.6050006@redhat.com> References: <4F60DED3.6050006@redhat.com> Message-ID: <4F60F5F6.8090206@redhat.com> On 3/14/2012 1:09 PM, Endi Sukma Dewata wrote: > The REST interface was vulnerable to injection attack. This has > been fixed by escaping the special characters in parameter values > before using them in the search filter. > > Ticket #96 ACKed by Ade. I added some clarification in the code. Pushed to master. -- Endi S. Dewata From cfu at redhat.com Wed Mar 14 21:49:37 2012 From: cfu at redhat.com (Christina) Date: Wed, 14 Mar 2012 14:49:37 -0700 Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived Message-ID: <4F611271.3080103@redhat.com> This is the ECC phase 2 implementation (ECC key archival / recovery feature) in the JSS and DRM (KRA) Bug: *Bug 745278* -[RFE] ECC encryption keys cannot be archived Please review the following patches (see "BEFORE you review" at later part of this email): * https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw * https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw * https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw thanks, Christina ============== BEFORE you review: For the ECC plan and design for the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. This patch contains code for the following packages: JSS, pki-kra, pki-common, pki-util, and pki-kra-ui What you need to know: * Problem 1 - nethsm issue: On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) * Problem 2- Certicom issue: This is a show-stopper. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are waiting for their fix. But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available. * Problem 3- Firefox with nethsm issue: Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) My solution (how I work on this official implementation): * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. I did some sanity test with the pkcs12 recovered: * Import the recovered pkcs12 into a certicom library: pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. About SELinux: I have a set of rules generated on my system to run in enforcing mode. I do a writeup. For QE: How to set up the servers? The internal wiki is at https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC. I might have given someone a copy of how to set up ECC CA to publish on fedora.org when I worked on phase1 back a couple years ago. I will put an updated copy to cover both CA and DRM when I am checking in to dogtag. How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above) It is not on my schedule to work on this tool; It is certainly not in production quality to be released as a regular tool. However, if you are interested in it, if we get enough request maybe we can think about doing something with it. Other test suggestion: I did not try to clone the ECC DRM. It's a good idea to test it out. For techpub: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfuECCtest.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5130 bytes Desc: S/MIME Cryptographic Signature URL: From edewata at redhat.com Wed Mar 14 23:30:33 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Mar 2012 18:30:33 -0500 Subject: [Pki-devel] [PATCH] 31 Removed unused variables (part 2). Message-ID: <4F612A19.3000503@redhat.com> This patch brings down the warnings from 2394 to 1638. Ticket #103 http://fedorapeople.org/gitweb?p=edewata/public_git/pki.git;a=commitdiff;h=41247a58d03976150670815875f146823b5ca688 It passed smoke test. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0031-Removed-unused-variables-part-2.patch Type: text/x-patch Size: 251411 bytes Desc: not available URL: From ayoung at redhat.com Thu Mar 15 01:47:46 2012 From: ayoung at redhat.com (Adam Young) Date: Wed, 14 Mar 2012 21:47:46 -0400 Subject: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch In-Reply-To: <4F5FF84A.1040701@redhat.com> References: <26ea132f-f7d7-4e84-83c8-55047cd2d1a9@zmail15.collab.prod.int.phx2.redhat.com> <4F5FF84A.1040701@redhat.com> Message-ID: <4F614A42.7020200@redhat.com> So while this is perfect for working with both PKI, and FreeIPA, for most of the JNDI/LDAP world, authorization consists of membership in groups. I believe the is how the original JNDI plugin works. When we extract this into its own RPM, we should keep that in mind, and allow the configuration to specify which way it is going to be used. From mharmsen at redhat.com Thu Mar 15 03:23:50 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 14 Mar 2012 20:23:50 -0700 Subject: [Pki-devel] Announcing 'Dogtag 10.0.0 (Alpha)' Message-ID: <4F6160C6.9060602@redhat.com> The Dogtag team is pleased to announce the availability of an Alpha Release of the Dogtag 10.0 code. This release contains the following features: 1. Extension of the functionality of the DRM to store and retrieve symmetric keys and passphrases, rather than only asymmetric keys. This feature allows the DRM to be used as a secure vault-like storage for essentially any sensitive data. The data is stored using the same secure FIPS-compliant storage mechanism used to store PKI keys. 2. The new DRM functionality is exposed through a new REST interface, provided by the RESTEasy framework. This provides an intuitive mechanism for writing clients to the interface. Both Java (using the RESTEasy client proxy framework) and Python clients have been coded. The server uses standard Java libraries to generate and parse XML or JSON input and output data. 3. Extracted authentication and authorization code from the individual servlets into a standard Tomcat authentication realm. This realm has been configured to require client certificate authentication, and is being used to secure the new DRM REST interface. In the future, this authentication realm could be extended to include other kinds of authentication (such as Kerberos). This is part of a push to refactor the code to expose the core business functionality in the servlets, while extracting the ancillary tasks (authentication, authorization, XML parsing and generation, etc.) and using standard methods and libraries to accomplish these tasks. 4. Enhanced Java subsystems so that they could connect to the internal database using a non-directory manager user, that is authenticated using client authentication. This resolves a number of issues with LDAP operations ignoring search limits. In addition, some changes have been made to allow integrating the Dogtag database with other systems such as IPA. 5. A new package pki-deploy contains the initial framework for a Python-based installer/de-installer (pkispawn/pkidestroy) that will be used to install and configure a Dogtag instance. This will ultimately replace the pki-setup installer/de-installer (pkicreate, pkidestroy) package, and the pki-silent instance configuration (pkisilent) package. 6. Much of the focus of this release was on cleaning up and modernizing the Dogtag source code. * Dogtag source code has been moved to git. * Java coding standards have been revised - and the code has been reformatted to match those standards. * Initially, Eclipse reported about 13000 warnings in the dogtag code. Those have been reduced to close to 2400. This included removing dead and unused code, replacing calls to deprecated functions and replacing raw collections with type-safe generics. NOTE: These numbers currently exclude console code. * OSUtil is a package that has certain utilities that were not available when the Dogtag code was originally written. These utilities are now available in current standard libraries - and so this package has been eliminated entirely. * Improved handling of short and long lived threads which allow threads to exit gracefully on shutdown. The builds can be found at the following links: * http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/RPMS/i686 - Fedora 16 (32-bit i686) * http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/RPMS/x86_64 - Fedora 16 (64-bit x86_64) * http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/SRPMS - Fedora 16 (Source) * http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/RPMS/i686 - Fedora 17 (32-bit i686) * http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/RPMS/x86_64 - Fedora 17 (64-bit x86_64) * http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/SRPMS - Fedora 17 (Source) From ayoung at redhat.com Thu Mar 15 18:29:59 2012 From: ayoung at redhat.com (Adam Young) Date: Thu, 15 Mar 2012 14:29:59 -0400 Subject: [Pki-devel] Announcing 'Dogtag 10.0.0 (Alpha)' In-Reply-To: <4F6160C6.9060602@redhat.com> References: <4F6160C6.9060602@redhat.com> Message-ID: <4F623527.2070704@redhat.com> On 03/14/2012 11:23 PM, Matthew Harmsen wrote: > The Dogtag team is pleased to announce the availability of an Alpha > Release of the Dogtag 10.0 code. > > This release contains the following features: > > 1. Extension of the functionality of the DRM to store and retrieve > symmetric keys and passphrases, > rather than only asymmetric keys. This feature allows the DRM to > be used as a secure > vault-like storage for essentially any sensitive data. The data is > stored using the same > secure FIPS-compliant storage mechanism used to store PKI keys. > 2. The new DRM functionality is exposed through a new REST interface, > provided by the RESTEasy > framework. This provides an intuitive mechanism for writing > clients to the interface. Both > Java (using the RESTEasy client proxy framework) and Python clients > have been coded. The > server uses standard Java libraries to generate and parse XML or > JSON input and output data. > 3. Extracted authentication and authorization code from the individual > servlets into a standard > Tomcat authentication realm. This realm has been configured to > require client certificate > authentication, and is being used to secure the new DRM REST > interface. In the future, this > authentication realm could be extended to include other kinds of > authentication (such as > Kerberos). This is part of a push to refactor the code to expose > the core business > functionality in the servlets, while extracting the ancillary tasks > (authentication, > authorization, XML parsing and generation, etc.) and using standard > methods and libraries to > accomplish these tasks. > 4. Enhanced Java subsystems so that they could connect to the internal > database using a > non-directory manager user, that is authenticated using client > authentication. This resolves a > number of issues with LDAP operations ignoring search limits. In > addition, some changes have > been made to allow integrating the Dogtag database with other > systems such as IPA. > 5. A new package pki-deploy contains the initial framework for a > Python-based > installer/de-installer (pkispawn/pkidestroy) that will be used to > install and configure a > Dogtag instance. This will ultimately replace the pki-setup > installer/de-installer > (pkicreate, pkidestroy) package, and the pki-silent instance > configuration (pkisilent) package. > 6. Much of the focus of this release was on cleaning up and > modernizing the Dogtag source code. > * Dogtag source code has been moved to git. > * Java coding standards have been revised - and the code has been > reformatted to match those > standards. > * Initially, Eclipse reported about 13000 warnings in the dogtag > code. Those have been reduced > to close to 2400. This included removing dead and unused code, > replacing calls to deprecated > functions and replacing raw collections with type-safe generics. > NOTE: These numbers currently exclude console code. > * OSUtil is a package that has certain utilities that were not > available when the Dogtag code > was originally written. These utilities are now available in > current standard > libraries - and so this package has been eliminated entirely. > * Improved handling of short and long lived threads which allow > threads to exit gracefully on > shutdown. > > The builds can be found at the following links: > > * > http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/RPMS/i686 > - Fedora 16 (32-bit i686) > * > http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/RPMS/x86_64 > - Fedora 16 (64-bit x86_64) > * > http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc16/SRPMS > - Fedora 16 (Source) > * > http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/RPMS/i686 > - Fedora 17 (32-bit i686) > * > http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/RPMS/x86_64 > - Fedora 17 (64-bit x86_64) > * > http://pki.fedoraproject.org/pki/download/pki/10.0.0.alpha/fc17/SRPMS > - Fedora 17 (Source) > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Nice work team. Well done. Time to try and break it! From jmagne at redhat.com Thu Mar 15 19:06:09 2012 From: jmagne at redhat.com (John Magne) Date: Thu, 15 Mar 2012 15:06:09 -0400 (EDT) Subject: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch In-Reply-To: <4F614A42.7020200@redhat.com> Message-ID: Most of the acls support group membership as part of their contraints. For this we make use of the inherited JNDI support to check to see if the user has the given role/group membership. Also, the code calls the base class method for authorization. Thus if the web.xml was configured with static roles and auth constraints, those checks would be done as well. ----- Original Message ----- From: "Adam Young" To: pki-devel at redhat.com Sent: Wednesday, March 14, 2012 6:47:46 PM Subject: Re: [Pki-devel] 0001-Provide-Custom-PKI-JNDI-Realm.patch So while this is perfect for working with both PKI, and FreeIPA, for most of the JNDI/LDAP world, authorization consists of membership in groups. I believe the is how the original JNDI plugin works. When we extract this into its own RPM, we should keep that in mind, and allow the configuration to specify which way it is going to be used. _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Mar 16 17:25:35 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 16 Mar 2012 13:25:35 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0023-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch Message-ID: <1331918735.8870.1.camel@aleeredhat.laptop> BZ 802396 - Change location of TOMCAT_LOG to match tomcat6 changes Tomcat6 has changed the changed the location of the TOMCAT_LOG, and it should no longer point to catalina.out. This initially caused dogtag to break because the code to chown TOMCAT_LOG to TOMCAT_USER was removed. Added code to spec file to fix existing instances. Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0023-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch Type: text/x-patch Size: 6404 bytes Desc: not available URL: From mharmsen at redhat.com Fri Mar 16 18:12:38 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 16 Mar 2012 11:12:38 -0700 Subject: [Pki-devel] [PATCH] pki-vakwetu-0023-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch In-Reply-To: <1331918735.8870.1.camel@aleeredhat.laptop> References: <1331918735.8870.1.camel@aleeredhat.laptop> Message-ID: <4F638296.5010705@redhat.com> On 03/16/12 10:25, Ade Lee wrote: > BZ 802396 - Change location of TOMCAT_LOG to match tomcat6 changes > > Tomcat6 has changed the changed the location of the TOMCAT_LOG, and > it should no longer point to catalina.out. This initially caused > dogtag to break because the code to chown TOMCAT_LOG to TOMCAT_USER > was removed. Added code to spec file to fix existing instances. > > 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 Mon Mar 19 19:12:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Mar 2012 14:12:53 -0500 Subject: [Pki-devel] [PATCH] 32 Replaced deprecated Date API. Message-ID: <4F678535.2030007@redhat.com> The deprecated Date(year, month, date) constructor has been replaced with Calendar API. There are similar Date constructors in JavaScript but those are not deprecated and should not be replaced. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0032-Replaced-deprecated-Date-API.patch Type: text/x-patch Size: 2996 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 19 19:12:58 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Mar 2012 14:12:58 -0500 Subject: [Pki-devel] [PATCH] 33 Removed unused SystemIdentity and SystemSigner. Message-ID: <4F67853A.2010203@redhat.com> The SystemIdentity and SystemSigner classes have been removed because they are based on deprecated classes and are not used anywhere in the code. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0033-Removed-unused-SystemIdentity-and-SystemSigner.patch Type: text/x-patch Size: 7732 bytes Desc: not available URL: From jmagne at redhat.com Tue Mar 20 00:41:07 2012 From: jmagne at redhat.com (John Magne) Date: Mon, 19 Mar 2012 20:41:07 -0400 (EDT) Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived In-Reply-To: <4F611271.3080103@redhat.com> Message-ID: <65b01b5a-dbec-476b-bcd0-05e364f89f13@zmail15.collab.prod.int.phx2.redhat.com> Took a look at this patch for ECC support. Comments and questions below. 1. KeyRecord.java line 273 public MetaInfo getMetaInfo() throws EBaseException { return mMetaInfo; } Why does this throw the EBaseException? All it does is return a value. 2. CryptUtil.java line 186 if (sensitive == 1 ) keygen.sensitivePairs(true); else if (sensitive == 0) keygen.sensitivePairs(false); if (extractable == 1 ) keygen.extractablePairs(true); else if (extractable == 0) keygen.extractablePairs(false); keygen.initialize(keysize); The values extractable and sensitive are sent in as integer? Should they be a boolean? I see the function calls have -1,-1 for those two final params. How does not setting sensitive and extractable different from setting them to false? I can see this being normal. 3. RecoveryService.java line 363 if (!isRSA) { CMS.debug("RecoverService: recoverKey: key to recover is RSA"); } else { CMS.debug("RecoverService: recoverKey: key to recover is not RSA"); } Would it not be simpler to print out the value of isRSA? 4. EnrollmentService.java line 451 metaInfo.set("EllipticCurve", oidDescription); I think in KeyRecord.java you have a static public member variable for "EllipticCurve" Probably should use that here for clarity. 5. ASN1Util.c line 58 SECItem *oid; Initialize to null? 6. ASN1Util.c line 78 oidTag = SECOID_FindOIDTag(oid); if (oidTag == SEC_OID_UNKNOWN) { JSS_throwMsg(env, INVALID_PARAMETER_EXCEPTION, "JSS getTagDescriptionByOid: OID UNKNOWN"); goto finish; } What if oidTag is null? Perhaps the call can never return this but some well known constant? 7. ASN1Uti.java line 126 Question, it looks like the routine takes in an entire public key blob as input. Would there be some simpler input that could end up giving us the same answer? I do not know. 8. Also, the routine throws a InvalidBERException exception or some such. There are a bunch of calls to methods such as : Arrays.copyOfRange That method appears to throw the following exceptions: ArrayIndexOutOfBoundsException - IllegalArgumentException - NullPointerException - Instead of catching only an "Exception" and forcing a "InvalidBERException", would it make sense to declare the function to also throw those exceptions? 8. Should we check for X509PubKeyBytes input parameter for null? 9. File displayBySerial.template line 103 if ((result.header.keyLength == null) || (result.header.keyLength <= 0)) { It looks like we use the above check to assume an ECC key. Is this the best way to make this determination? Is there any info that actually tells us we have an ECC key instead of this lack of information? Actually it looks like this check is used everywhere in this part of the patch when a decision is needed. ----- Original Message ----- From: "Christina" To: pki-devel at redhat.com Sent: Wednesday, March 14, 2012 2:49:37 PM Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived This is the ECC phase 2 implementation (ECC key archival / recovery feature) in the JSS and DRM (KRA) Bug: Bug 745278 - [RFE] ECC encryption keys cannot be archived Please review the following patches (see "BEFORE you review" at later part of this email): * https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw * https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw * https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw thanks, Christina ============== BEFORE you review: For the ECC plan and design for the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. This patch contains code for the following packages: JSS, pki-kra, pki-common, pki-util, and pki-kra-ui What you need to know: * Problem 1 - nethsm issue: On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) * Problem 2- Certicom issue: This is a show-stopper. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are waiting for their fix. But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available. * Problem 3- Firefox with nethsm issue: Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) My solution (how I work on this official implementation): * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. I did some sanity test with the pkcs12 recovered: * Import the recovered pkcs12 into a certicom library: pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. About SELinux: I have a set of rules generated on my system to run in enforcing mode. I do a writeup. For QE: How to set up the servers? The internal wiki is at https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC . I might have given someone a copy of how to set up ECC CA to publish on fedora.org when I worked on phase1 back a couple years ago. I will put an updated copy to cover both CA and DRM when I am checking in to dogtag. How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above) It is not on my schedule to work on this tool; It is certainly not in production quality to be released as a regular tool. However, if you are interested in it, if we get enough request maybe we can think about doing something with it. Other test suggestion: I did not try to clone the ECC DRM. It's a good idea to test it out. For techpub: TBD _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Tue Mar 20 01:00:58 2012 From: cfu at redhat.com (Christina Fu) Date: Mon, 19 Mar 2012 18:00:58 -0700 Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived In-Reply-To: <65b01b5a-dbec-476b-bcd0-05e364f89f13@zmail15.collab.prod.int.phx2.redhat.com> References: <65b01b5a-dbec-476b-bcd0-05e364f89f13@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F67D6CA.6040302@redhat.com> On 03/19/2012 05:41 PM, John Magne wrote: > > Took a look at this patch for ECC support. > > Comments and questions below. > > > 1. > > KeyRecord.java line 273 > > public MetaInfo getMetaInfo() throws EBaseException { > > return mMetaInfo; > > } > > > Why does this throw the EBaseException? > All it does is return a value. > yes, it does not need to declare such throw of exception, even though it is the trend in that file and I was just copying them. Will change. > 2. > > > CryptUtil.java line 186 > > if (sensitive == 1 ) > > keygen.sensitivePairs(true); > > else if (sensitive == 0) > > keygen.sensitivePairs(false); > > if (extractable == 1 ) > > keygen.extractablePairs(true); > > else if (extractable == 0) > > keygen.extractablePairs(false); > > > keygen.initialize(keysize); > > > > > The values extractable and sensitive are sent in as integer? > Should they be a boolean? I see the function calls have -1,-1 > for those two final params. How does not setting sensitive and > extractable different from setting them to false? > > I can see this being normal. As explained in the comment, the definitions are defined in JSS pkcs11/PK11KeyPairGenerator.java, so I just followed the definition. For your information, here is what it says in JSS: private boolean temporaryPairMode = false; // 1: sensitive // 0: insensitive // -1: sensitive if temporaryPairMode is false, // insensitive if temporaryPairMode is true // (the default depends on temporaryPairMode for backward // compatibility) private int sensitivePairMode = -1; // 1: extractable // 0: unextractable // -1: unspecified (token dependent) private int extractablePairMode = -1; > > 3. > > RecoveryService.java line 363 > > > if (!isRSA) { > CMS.debug("RecoverService: recoverKey: key to recover is RSA"); > } else { > > CMS.debug("RecoverService: recoverKey: key to recover is not RSA"); > } > > Would it not be simpler to print out the value of isRSA? It really does not matter. A smarter question would be, why did I even bother to have "isRSA" parameter for this method? The reason is that there is an existing recoverKey for RSA, and the function signature does not take return type into account so it doesn't allow polyinstantiation of the function unless I add one more parameter to it. So I added this isRSA param which really serves no purpose other than getting the JAVA compiler to comply. That said, I'll change it so that it prints isRSA instead. > > 4. > > EnrollmentService.java line 451 > > metaInfo.set("EllipticCurve", oidDescription); > > I think in KeyRecord.java you have a static public member variable for "EllipticCurve" > Probably should use that here for clarity. Will do > > 5. > > ASN1Util.c line 58 > > SECItem *oid; > > Initialize to null? will do > > 6. > > > ASN1Util.c line 78 > > oidTag = SECOID_FindOIDTag(oid); > > if (oidTag == SEC_OID_UNKNOWN) { > > JSS_throwMsg(env, INVALID_PARAMETER_EXCEPTION, > > "JSS getTagDescriptionByOid: OID UNKNOWN"); > > goto finish; > > } > > What if oidTag is null? Perhaps the call can never return this but some well known constant? It can't be. It was initialized to SEC_OID_UNKNOWN, and NSS returns SEC_OID_UNKNOWN to you as well if it can't find it. I will add comment to explain. > > 7. > > > ASN1Uti.java line 126 > > Question, it looks like the routine takes in an entire public key blob as input. > Would there be some simpler input that could end up giving us the same answer? I do not know. There isn't any. You would have to require callers to parse down the pubkey if we take a smaller byte array for this function. > > 8. > > Also, the routine throws a InvalidBERException exception or some such. > > There are a bunch of calls to methods such as : Arrays.copyOfRange > > That method appears to throw the following exceptions: > > ArrayIndexOutOfBoundsException - > IllegalArgumentException - > NullPointerException - > > Instead of catching only an "Exception" and forcing a "InvalidBERException", would it make sense to > declare the function to also throw those exceptions? > will do > 8. > > > Should we check for X509PubKeyBytes input parameter for null? will do > > 9. > > > File displayBySerial.template line 103 > > if ((result.header.keyLength == null) || (result.header.keyLength<= 0)) { > > It looks like we use the above check to assume an ECC key. Is this the best way to make > this determination? Is there any info that actually tells us we have an ECC key instead of this > lack of information? > > Actually it looks like this check is used everywhere in this part of the patch when a decision is needed. > > I wonder about that myself. I use rec.EllipticCurve != null at certain places which worked well, but at some specific places, I couldn't for some reason. That's why I used<=0 check. I can try again. > > > > > ----- Original Message ----- > From: "Christina" > To: pki-devel at redhat.com > Sent: Wednesday, March 14, 2012 2:49:37 PM > Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived > > > > This is the ECC phase 2 implementation (ECC key archival / recovery feature) in the JSS and DRM (KRA) > > Bug: Bug 745278 - [RFE] ECC encryption keys cannot be archived > > Please review the following patches (see "BEFORE you review" at later part of this email): > > * https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw > * https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw > * https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw > > thanks, > Christina > ============== > BEFORE you review: > > For the ECC plan and design for the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag > > Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. > > This patch contains code for the following packages: > JSS, pki-kra, pki-common, pki-util, and pki-kra-ui > > What you need to know: > > * Problem 1 - nethsm issue: > On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) > > * Problem 2- Certicom issue: > This is a show-stopper. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are waiting for their fix. > > But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. > In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. > > A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available. > > * Problem 3- Firefox with nethsm issue: > Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) > > My solution (how I work on this official implementation): > * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. > This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) > Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. > For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. > > I did some sanity test with the pkcs12 recovered: > * Import the recovered pkcs12 into a certicom library: > pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 > > I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. > > Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. > > About SELinux: > I have a set of rules generated on my system to run in enforcing mode. I do a writeup. > > For QE: > How to set up the servers? The internal wiki is at https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC . I might have given someone a copy of how to set up ECC CA to publish on fedora.org when I worked on phase1 back a couple years ago. I will put an updated copy to cover both CA and DRM when I am checking in to dogtag. > > How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above) > It is not on my schedule to work on this tool; It is certainly not in production quality to be released as a regular tool. However, if you are interested in it, if we get enough request maybe we can think about doing something with it. > Other test suggestion: I did not try to clone the ECC DRM. It's a good idea to test it out. > > For techpub: > TBD > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5130 bytes Desc: S/MIME Cryptographic Signature URL: From alee at redhat.com Tue Mar 20 19:27:29 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 20 Mar 2012 15:27:29 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0024-Allow-clones-to-specify-master-and-replica-ports-and.patch Message-ID: <1332271650.14538.6.camel@aleeredhat.laptop> Allow clones to specify master and replica ports and security options Removed -clone_start_tls option and subsumed it into -replicationSecurity. Refactored DatabasePanel parameter verification code to allow it to be used in both update() and validate(). Added new parameters to pkisilent and databasepanel.vm. Fixed pkisilent deprecation errors. Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0024-Allow-clones-to-specify-master-and-replica-ports-and.patch Type: text/x-patch Size: 139571 bytes Desc: not available URL: From cfu at redhat.com Tue Mar 20 22:08:33 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 20 Mar 2012 15:08:33 -0700 Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived In-Reply-To: <4F67D6CA.6040302@redhat.com> References: <65b01b5a-dbec-476b-bcd0-05e364f89f13@zmail15.collab.prod.int.phx2.redhat.com> <4F67D6CA.6040302@redhat.com> Message-ID: <4F68FFE1.2000403@redhat.com> JSS part rolled in comments, please review again: https://bugzilla.redhat.com/attachment.cgi?id=571545&action=diff&context=patch&collapsed=&headers=1&format=raw Note: all other CS components have dependency on the availability of this patch, so this one needs to be ack'd separately ahead of time. thanks, Christina On 03/19/2012 06:00 PM, Christina Fu wrote: > On 03/19/2012 05:41 PM, John Magne wrote: >> >> Took a look at this patch for ECC support. >> >> Comments and questions below. >> >> >> 1. >> >> KeyRecord.java line 273 >> >> public MetaInfo getMetaInfo() throws EBaseException { >> >> return mMetaInfo; >> >> } >> >> >> Why does this throw the EBaseException? >> All it does is return a value. >> > > yes, it does not need to declare such throw of exception, even though > it is the trend in that file and I was just copying them. Will change. > >> 2. >> >> >> CryptUtil.java line 186 >> >> if (sensitive == 1 ) >> >> keygen.sensitivePairs(true); >> >> else if (sensitive == 0) >> >> keygen.sensitivePairs(false); >> >> if (extractable == 1 ) >> >> keygen.extractablePairs(true); >> >> else if (extractable == 0) >> >> keygen.extractablePairs(false); >> >> >> keygen.initialize(keysize); >> >> >> >> >> The values extractable and sensitive are sent in as integer? >> Should they be a boolean? I see the function calls have -1,-1 >> for those two final params. How does not setting sensitive and >> extractable different from setting them to false? >> >> I can see this being normal. > > As explained in the comment, the definitions are defined in JSS > pkcs11/PK11KeyPairGenerator.java, so I just followed the definition. > For your information, here is what it says in JSS: > private boolean temporaryPairMode = false; > // 1: sensitive > // 0: insensitive > // -1: sensitive if temporaryPairMode is false, > // insensitive if temporaryPairMode is true > // (the default depends on temporaryPairMode for backward > // compatibility) > private int sensitivePairMode = -1; > // 1: extractable > // 0: unextractable > // -1: unspecified (token dependent) > private int extractablePairMode = -1; > >> >> 3. >> >> RecoveryService.java line 363 >> >> >> if (!isRSA) { >> CMS.debug("RecoverService: recoverKey: key to recover is >> RSA"); >> } else { >> >> CMS.debug("RecoverService: recoverKey: key to recover is >> not RSA"); >> } >> >> Would it not be simpler to print out the value of isRSA? > > It really does not matter. A smarter question would be, why did I even > bother to have "isRSA" parameter for this method? The reason is that > there is an existing recoverKey for RSA, and the function signature does > not take return type into account so it doesn't allow polyinstantiation > of the function unless I add one more parameter to it. So I added this > isRSA param which really serves no purpose other than getting the JAVA > compiler to comply. > That said, I'll change it so that it prints isRSA instead. > >> >> 4. >> >> EnrollmentService.java line 451 >> >> metaInfo.set("EllipticCurve", oidDescription); >> >> I think in KeyRecord.java you have a static public member variable >> for "EllipticCurve" >> Probably should use that here for clarity. > > Will do > >> >> 5. >> >> ASN1Util.c line 58 >> >> SECItem *oid; >> >> Initialize to null? > > will do > >> >> 6. >> >> >> ASN1Util.c line 78 >> >> oidTag = SECOID_FindOIDTag(oid); >> >> if (oidTag == SEC_OID_UNKNOWN) { >> >> JSS_throwMsg(env, INVALID_PARAMETER_EXCEPTION, >> >> "JSS getTagDescriptionByOid: OID UNKNOWN"); >> >> goto finish; >> >> } >> >> What if oidTag is null? Perhaps the call can never return this but >> some well known constant? > > It can't be. It was initialized to SEC_OID_UNKNOWN, and NSS returns > SEC_OID_UNKNOWN to you as well if it can't find it. > I will add comment to explain. > > >> >> 7. >> >> >> ASN1Uti.java line 126 >> >> Question, it looks like the routine takes in an entire public key >> blob as input. >> Would there be some simpler input that could end up giving us the >> same answer? I do not know. > There isn't any. You would have to require callers to parse down the > pubkey if we take a smaller byte array for this function. > >> >> 8. >> >> Also, the routine throws a InvalidBERException exception or some such. >> >> There are a bunch of calls to methods such as : Arrays.copyOfRange >> >> That method appears to throw the following exceptions: >> >> ArrayIndexOutOfBoundsException - >> IllegalArgumentException - >> NullPointerException - >> >> Instead of catching only an "Exception" and forcing a >> "InvalidBERException", would it make sense to >> declare the function to also throw those exceptions? >> > will do >> 8. >> >> >> Should we check for X509PubKeyBytes input parameter for null? > will do >> >> 9. >> >> >> File displayBySerial.template line 103 >> >> if ((result.header.keyLength == null) || (result.header.keyLength<= >> 0)) { >> >> It looks like we use the above check to assume an ECC key. Is this >> the best way to make >> this determination? Is there any info that actually tells us we have >> an ECC key instead of this >> lack of information? >> >> Actually it looks like this check is used everywhere in this part of >> the patch when a decision is needed. >> >> > I wonder about that myself. I use rec.EllipticCurve != null at certain > places which worked well, but at some specific places, I couldn't for > some reason. That's why I used<=0 check. > I can try again. >> >> >> >> >> ----- Original Message ----- >> From: "Christina" >> To: pki-devel at redhat.com >> Sent: Wednesday, March 14, 2012 2:49:37 PM >> Subject: [Pki-devel] patches for review - ECC key archival / recovery >> feature implementation - Bug 745278 - [RFE] ECC encryption keys >> cannot be archived >> >> >> >> This is the ECC phase 2 implementation (ECC key archival / recovery >> feature) in the JSS and DRM (KRA) >> >> Bug: Bug 745278 - [RFE] ECC encryption keys cannot be archived >> >> Please review the following patches (see "BEFORE you review" at later >> part of this email): >> >> * >> https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw >> * >> https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw >> * >> https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw >> >> thanks, >> Christina >> ============== >> BEFORE you review: >> >> For the ECC plan and design for the different phases, please refer to >> http://pki.fedoraproject.org/wiki/ECC_in_Dogtag >> >> Note: the designs beyond phase 2 were more like a brain dump. >> Although I said "Do Not Review," you are free to take a peak at >> what's intended down the road. I will go back and take a closer look >> and refine/adjust the designs when I begin implementation for each >> new phase. >> >> This patch contains code for the following packages: >> JSS, pki-kra, pki-common, pki-util, and pki-kra-ui >> >> What you need to know: >> >> * Problem 1 - nethsm issue: >> On the server side, if you turn on FIPS mode, in addition to nethsm, >> you need to attach certicom as well to have ECC SSL working on the >> server side. This problem has already been reported to Thales last >> year and they said they'd look into putting the item on their next >> release. Recently through a different contact, we learned there might >> be a way to "turn it on" (still waiting for their further instruction) >> >> * Problem 2- Certicom issue: >> This is a show-stopper. Initially, on the client side, I used Kai's >> special version of Xulrunner/Firefox, attached to Certicom token, so >> that the CRMF requests can be generated with key archival option. >> However, I encountered (or, re-encountered) an issue with certicom >> token. Certicom generates ECC keys with the wrong format (not PKCS7 >> conforming), which makes ECC key archival impossible on the server >> side if you use non-certicom token with DRM (but we expect an HSM in >> most product deployment). I have contacted Certicom for this issue, >> and they confirmed that they indeed have such issue. We are waiting >> for their fix. >> >> But then you might ask, "I thought I saw some ECC enrollment >> profiles/javascripts being checked in? How were the tests done?" The >> tests for those profiles were done against this ECC key >> archival/recovery DRM prototype I implemented last year (needs to be >> turned on manually in 8.1), where I "cheated" (yeah, that's why it's >> called a prototype) by decrypting the private key in the CRMF on DRM, >> and then manipulating the byte array to strip off the offending bytes >> before archival. >> In the real, non-prototype implementation, which is what's in this >> patch, for security reasons, private keys are unwrapped directly onto >> the token during key archival, so there is no way to manipulate the >> keys in memory and bypass the Certicom issue. >> >> A word about Kai's special version of Xulrunner/Firefox. It is not >> yet publicly available. >> >> * Problem 3- Firefox with nethsm issue: >> Another option was to connect Kai's special version firefox with an >> HSM to test my DRM/JSS code. However, for whatever reason, I could >> not get SSL going between such Firefox and ECC CA ( I did not try >> very hard though, as I have one other option -- writing my own ECC >> CRMF generation tool. I might come back to try the nethsm Firefox >> idea later) >> >> My solution (how I work on this official implementation): >> * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing >> in current releases), gutting out the RSA part of the code, and >> replacing it with ECC code. I call it CRMFPopClientEC. Two types of >> ECC key pairs could be generated: ECDSA or ECDH (That's another >> benefit of writing my own tool -- I don't know if you can select >> which type to generate in the Javascript... maybe you can, I just >> don't know). I'm in no way condoning archival of signing keys!! This >> is just a test tool. >> This tool takes a curve name as option (along with others), generates >> an ECC key pair, crafts up an CRMF request with key archival option, >> and sends request directly to the specified CA. You will see a >> "Deferred" message in the HTML response (see attachment for example) >> Once CA agent approves the request, the archival request goes to DRM >> and the user private key is archived. >> For recovery, DRM agent selects key recovery, etc, and you get your >> pkcs12. >> >> I did some sanity test with the pkcs12 recovered: >> * Import the recovered pkcs12 into a certicom library: >> pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 >> >> I also tested by retrieving a p12, importing it into a browser, and >> adding the user as an agent and the user could act as agent via ssl >> client auth to the CA. >> >> Finally, much of the RSA-centric code had been cleared out of the way >> at the time when I worked on the DRM ECC prototype, so you don't see >> much of that in this round. >> >> About SELinux: >> I have a set of rules generated on my system to run in enforcing >> mode. I do a writeup. >> >> For QE: >> How to set up the servers? The internal wiki is at >> https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC . >> I might have given someone a copy of how to set up ECC CA to publish >> on fedora.org when I worked on phase1 back a couple years ago. I will >> put an updated copy to cover both CA and DRM when I am checking in to >> dogtag. >> >> How do you test? Well, unless you want to use my CRMFPopClientEC tool >> hooked up with a nethsm (like I did), or write your own tool, you >> can't really test it until Certicom fixes their issue. (BTW >> CRMFPopClientEC can also be changed to work with ceriticom, although >> you would run into the same issue I mentioned above) >> It is not on my schedule to work on this tool; It is certainly not in >> production quality to be released as a regular tool. However, if you >> are interested in it, if we get enough request maybe we can think >> about doing something with it. >> Other test suggestion: I did not try to clone the ECC DRM. It's a >> good idea to test it out. >> >> For techpub: >> TBD >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5130 bytes Desc: S/MIME Cryptographic Signature URL: From jmagne at redhat.com Tue Mar 20 23:40:12 2012 From: jmagne at redhat.com (John Magne) Date: Tue, 20 Mar 2012 19:40:12 -0400 (EDT) Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived In-Reply-To: <4F68FFE1.2000403@redhat.com> Message-ID: <474179b6-6886-4cd5-b275-416744b08239@zmail15.collab.prod.int.phx2.redhat.com> Based on provided changes: Attachment #571545: jss-ECC-Phase2KeyArchivalRecovery.patch only: ACK ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, March 20, 2012 3:08:33 PM Subject: Re: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived JSS part rolled in comments, please review again: https://bugzilla.redhat.com/attachment.cgi?id=571545&action=diff&context=patch&collapsed=&headers=1&format=raw Note: all other CS components have dependency on the availability of this patch, so this one needs to be ack'd separately ahead of time. thanks, Christina On 03/19/2012 06:00 PM, Christina Fu wrote: On 03/19/2012 05:41 PM, John Magne wrote: Took a look at this patch for ECC support. Comments and questions below. 1. KeyRecord.java line 273 public MetaInfo getMetaInfo() throws EBaseException { return mMetaInfo; } Why does this throw the EBaseException? All it does is return a value. yes, it does not need to declare such throw of exception, even though it is the trend in that file and I was just copying them. Will change. 2. CryptUtil.java line 186 if (sensitive == 1 ) keygen.sensitivePairs(true); else if (sensitive == 0) keygen.sensitivePairs(false); if (extractable == 1 ) keygen.extractablePairs(true); else if (extractable == 0) keygen.extractablePairs(false); keygen.initialize(keysize); The values extractable and sensitive are sent in as integer? Should they be a boolean? I see the function calls have -1,-1 for those two final params. How does not setting sensitive and extractable different from setting them to false? I can see this being normal. As explained in the comment, the definitions are defined in JSS pkcs11/PK11KeyPairGenerator.java, so I just followed the definition. For your information, here is what it says in JSS: private boolean temporaryPairMode = false; // 1: sensitive // 0: insensitive // -1: sensitive if temporaryPairMode is false, // insensitive if temporaryPairMode is true // (the default depends on temporaryPairMode for backward // compatibility) private int sensitivePairMode = -1; // 1: extractable // 0: unextractable // -1: unspecified (token dependent) private int extractablePairMode = -1; 3. RecoveryService.java line 363 if (!isRSA) { CMS.debug("RecoverService: recoverKey: key to recover is RSA"); } else { CMS.debug("RecoverService: recoverKey: key to recover is not RSA"); } Would it not be simpler to print out the value of isRSA? It really does not matter. A smarter question would be, why did I even bother to have "isRSA" parameter for this method? The reason is that there is an existing recoverKey for RSA, and the function signature does not take return type into account so it doesn't allow polyinstantiation of the function unless I add one more parameter to it. So I added this isRSA param which really serves no purpose other than getting the JAVA compiler to comply. That said, I'll change it so that it prints isRSA instead. 4. EnrollmentService.java line 451 metaInfo.set("EllipticCurve", oidDescription); I think in KeyRecord.java you have a static public member variable for "EllipticCurve" Probably should use that here for clarity. Will do 5. ASN1Util.c line 58 SECItem *oid; Initialize to null? will do 6. ASN1Util.c line 78 oidTag = SECOID_FindOIDTag(oid); if (oidTag == SEC_OID_UNKNOWN) { JSS_throwMsg(env, INVALID_PARAMETER_EXCEPTION, "JSS getTagDescriptionByOid: OID UNKNOWN"); goto finish; } What if oidTag is null? Perhaps the call can never return this but some well known constant? It can't be. It was initialized to SEC_OID_UNKNOWN, and NSS returns SEC_OID_UNKNOWN to you as well if it can't find it. I will add comment to explain. 7. ASN1Uti.java line 126 Question, it looks like the routine takes in an entire public key blob as input. Would there be some simpler input that could end up giving us the same answer? I do not know. There isn't any. You would have to require callers to parse down the pubkey if we take a smaller byte array for this function. 8. Also, the routine throws a InvalidBERException exception or some such. There are a bunch of calls to methods such as : Arrays.copyOfRange That method appears to throw the following exceptions: ArrayIndexOutOfBoundsException - IllegalArgumentException - NullPointerException - Instead of catching only an "Exception" and forcing a "InvalidBERException", would it make sense to declare the function to also throw those exceptions? will do 8. Should we check for X509PubKeyBytes input parameter for null? will do 9. File displayBySerial.template line 103 if ((result.header.keyLength == null) || (result.header.keyLength<= 0)) { It looks like we use the above check to assume an ECC key. Is this the best way to make this determination? Is there any info that actually tells us we have an ECC key instead of this lack of information? Actually it looks like this check is used everywhere in this part of the patch when a decision is needed. I wonder about that myself. I use rec.EllipticCurve != null at certain places which worked well, but at some specific places, I couldn't for some reason. That's why I used<=0 check. I can try again. ----- Original Message ----- From: "Christina" To: pki-devel at redhat.com Sent: Wednesday, March 14, 2012 2:49:37 PM Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived This is the ECC phase 2 implementation (ECC key archival / recovery feature) in the JSS and DRM (KRA) Bug: Bug 745278 - [RFE] ECC encryption keys cannot be archived Please review the following patches (see "BEFORE you review" at later part of this email): * https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw * https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw * https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw thanks, Christina ============== BEFORE you review: For the ECC plan and design for the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. This patch contains code for the following packages: JSS, pki-kra, pki-common, pki-util, and pki-kra-ui What you need to know: * Problem 1 - nethsm issue: On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) * Problem 2- Certicom issue: This is a show-stopper. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are waiting for their fix. But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available. * Problem 3- Firefox with nethsm issue: Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) My solution (how I work on this official implementation): * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. I did some sanity test with the pkcs12 recovered: * Import the recovered pkcs12 into a certicom library: pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. About SELinux: I have a set of rules generated on my system to run in enforcing mode. I do a writeup. For QE: How to set up the servers? The internal wiki is at https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC . I might have given someone a copy of how to set up ECC CA to publish on fedora.org when I worked on phase1 back a couple years ago. I will put an updated copy to cover both CA and DRM when I am checking in to dogtag. How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above) It is not on my schedule to work on this tool; It is certainly not in production quality to be released as a regular tool. However, if you are interested in it, if we get enough request maybe we can think about doing something with it. Other test suggestion: I did not try to clone the ECC DRM. It's a good idea to test it out. For techpub: TBD _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From cfu at redhat.com Wed Mar 21 17:29:06 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 21 Mar 2012 10:29:06 -0700 Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived In-Reply-To: <474179b6-6886-4cd5-b275-416744b08239@zmail15.collab.prod.int.phx2.redhat.com> References: <474179b6-6886-4cd5-b275-416744b08239@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4F6A0FE2.7060106@redhat.com> Here are the CS patches with comments rolled in. Please review: https://bugzilla.redhat.com/attachment.cgi?id=571781&action=diff&context=patch&collapsed=&headers=1&format=raw https://bugzilla.redhat.com/attachment.cgi?id=571782&action=diff&context=patch&collapsed=&headers=1&format=raw Please note that they will not be checked in until the new JSS build is ready. Also, a demo was conducted. thanks, Christina On 03/20/2012 04:40 PM, John Magne wrote: > Based on provided changes: > > Attachment #571545: jss-ECC-Phase2KeyArchivalRecovery.patch only: > > ACK > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, March 20, 2012 3:08:33 PM > Subject: Re: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived > > > JSS part rolled in comments, please review again: > https://bugzilla.redhat.com/attachment.cgi?id=571545&action=diff&context=patch&collapsed=&headers=1&format=raw > > Note: all other CS components have dependency on the availability of this patch, so this one needs to be ack'd separately ahead of time. > > thanks, > Christina > > > On 03/19/2012 06:00 PM, Christina Fu wrote: > > On 03/19/2012 05:41 PM, John Magne wrote: > > > > Took a look at this patch for ECC support. > > Comments and questions below. > > > 1. > > KeyRecord.java line 273 > > public MetaInfo getMetaInfo() throws EBaseException { > > return mMetaInfo; > > } > > > Why does this throw the EBaseException? > All it does is return a value. > > > yes, it does not need to declare such throw of exception, even though it is the trend in that file and I was just copying them. Will change. > > > > 2. > > > CryptUtil.java line 186 > > if (sensitive == 1 ) > > keygen.sensitivePairs(true); > > else if (sensitive == 0) > > keygen.sensitivePairs(false); > > if (extractable == 1 ) > > keygen.extractablePairs(true); > > else if (extractable == 0) > > keygen.extractablePairs(false); > > > keygen.initialize(keysize); > > > > > The values extractable and sensitive are sent in as integer? > Should they be a boolean? I see the function calls have -1,-1 > for those two final params. How does not setting sensitive and > extractable different from setting them to false? > > I can see this being normal. > > As explained in the comment, the definitions are defined in JSS > pkcs11/PK11KeyPairGenerator.java, so I just followed the definition. > For your information, here is what it says in JSS: > private boolean temporaryPairMode = false; > // 1: sensitive > // 0: insensitive > // -1: sensitive if temporaryPairMode is false, > // insensitive if temporaryPairMode is true > // (the default depends on temporaryPairMode for backward > // compatibility) > private int sensitivePairMode = -1; > // 1: extractable > // 0: unextractable > // -1: unspecified (token dependent) > private int extractablePairMode = -1; > > > > > 3. > > RecoveryService.java line 363 > > > if (!isRSA) { > CMS.debug("RecoverService: recoverKey: key to recover is RSA"); > } else { > > CMS.debug("RecoverService: recoverKey: key to recover is not RSA"); > } > > Would it not be simpler to print out the value of isRSA? > > It really does not matter. A smarter question would be, why did I even > bother to have "isRSA" parameter for this method? The reason is that > there is an existing recoverKey for RSA, and the function signature does > not take return type into account so it doesn't allow polyinstantiation > of the function unless I add one more parameter to it. So I added this > isRSA param which really serves no purpose other than getting the JAVA compiler to comply. > That said, I'll change it so that it prints isRSA instead. > > > > > 4. > > EnrollmentService.java line 451 > > metaInfo.set("EllipticCurve", oidDescription); > > I think in KeyRecord.java you have a static public member variable for "EllipticCurve" > Probably should use that here for clarity. > > Will do > > > > > 5. > > ASN1Util.c line 58 > > SECItem *oid; > > Initialize to null? > > will do > > > > > 6. > > > ASN1Util.c line 78 > > oidTag = SECOID_FindOIDTag(oid); > > if (oidTag == SEC_OID_UNKNOWN) { > > JSS_throwMsg(env, INVALID_PARAMETER_EXCEPTION, > > "JSS getTagDescriptionByOid: OID UNKNOWN"); > > goto finish; > > } > > What if oidTag is null? Perhaps the call can never return this but some well known constant? > > It can't be. It was initialized to SEC_OID_UNKNOWN, and NSS returns > SEC_OID_UNKNOWN to you as well if it can't find it. > I will add comment to explain. > > > > > > 7. > > > ASN1Uti.java line 126 > > Question, it looks like the routine takes in an entire public key blob as input. > Would there be some simpler input that could end up giving us the same answer? I do not know. > There isn't any. You would have to require callers to parse down the > pubkey if we take a smaller byte array for this function. > > > > > 8. > > Also, the routine throws a InvalidBERException exception or some such. > > There are a bunch of calls to methods such as : Arrays.copyOfRange > > That method appears to throw the following exceptions: > > ArrayIndexOutOfBoundsException - > IllegalArgumentException - > NullPointerException - > > Instead of catching only an "Exception" and forcing a "InvalidBERException", would it make sense to > declare the function to also throw those exceptions? > > will do > > > 8. > > > Should we check for X509PubKeyBytes input parameter for null? > will do > > > > 9. > > > File displayBySerial.template line 103 > > if ((result.header.keyLength == null) || (result.header.keyLength<= 0)) { > > It looks like we use the above check to assume an ECC key. Is this the best way to make > this determination? Is there any info that actually tells us we have an ECC key instead of this > lack of information? > > Actually it looks like this check is used everywhere in this part of the patch when a decision is needed. > > > I wonder about that myself. I use rec.EllipticCurve != null at certain > places which worked well, but at some specific places, I couldn't for > some reason. That's why I used<=0 check. > I can try again. > > > > > > > ----- Original Message ----- > From: "Christina" > To: pki-devel at redhat.com > Sent: Wednesday, March 14, 2012 2:49:37 PM > Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived > > > > This is the ECC phase 2 implementation (ECC key archival / recovery feature) in the JSS and DRM (KRA) > > Bug: Bug 745278 - [RFE] ECC encryption keys cannot be archived > > Please review the following patches (see "BEFORE you review" at later part of this email): > > * https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw > * https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw > * https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw > > thanks, > Christina > ============== > BEFORE you review: > > For the ECC plan and design for the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag > > Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. > > This patch contains code for the following packages: > JSS, pki-kra, pki-common, pki-util, and pki-kra-ui > > What you need to know: > > * Problem 1 - nethsm issue: > On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) > > * Problem 2- Certicom issue: > This is a show-stopper. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are waiting for their fix. > > But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. > In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. > > A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available. > > * Problem 3- Firefox with nethsm issue: > Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) > > My solution (how I work on this official implementation): > * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. > This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) > Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. > For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. > > I did some sanity test with the pkcs12 recovered: > * Import the recovered pkcs12 into a certicom library: > pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 > > I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. > > Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. > > About SELinux: > I have a set of rules generated on my system to run in enforcing mode. I do a writeup. > > For QE: > How to set up the servers? The internal wiki is at https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC . I might have given someone a copy of how to set up ECC CA to publish on fedora.org when I worked on phase1 back a couple years ago. I will put an updated copy to cover both CA and DRM when I am checking in to dogtag. > > How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above) > It is not on my schedule to work on this tool; It is certainly not in production quality to be released as a regular tool. However, if you are interested in it, if we get enough request maybe we can think about doing something with it. > Other test suggestion: I did not try to clone the ECC DRM. It's a good idea to test it out. > > For techpub: > TBD > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5130 bytes Desc: S/MIME Cryptographic Signature URL: From alee at redhat.com Wed Mar 21 19:15:44 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 15:15:44 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0025-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch Message-ID: <1332357344.32649.1.camel@aleeredhat.laptop> This change is for the IPA_RHEL6 branch. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0025-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch Type: text/x-patch Size: 14029 bytes Desc: not available URL: From mharmsen at redhat.com Wed Mar 21 19:31:43 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 12:31:43 -0700 Subject: [Pki-devel] [PATCH] pki-vakwetu-0025-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch In-Reply-To: <1332357344.32649.1.camel@aleeredhat.laptop> References: <1332357344.32649.1.camel@aleeredhat.laptop> Message-ID: <4F6A2C9F.6060609@redhat.com> On 03/21/12 12:15, Ade Lee wrote: > This change is for the IPA_RHEL6 branch. Please review. > > 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 alee at redhat.com Wed Mar 21 20:01:57 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 16:01:57 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0025-BZ-802396-Change-location-of-TOMCAT_LOG-to-match-tom.patch In-Reply-To: <4F6A2C9F.6060609@redhat.com> References: <1332357344.32649.1.camel@aleeredhat.laptop> <4F6A2C9F.6060609@redhat.com> Message-ID: <1332360118.32649.2.camel@aleeredhat.laptop> Pushed to IPA RHEL 6 branch On Wed, 2012-03-21 at 12:31 -0700, Matthew Harmsen wrote: > On 03/21/12 12:15, Ade Lee wrote: > > This change is for the IPA_RHEL6 branch. Please review. > > > > Ade > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > ACK From mharmsen at redhat.com Wed Mar 21 21:30:02 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 14:30:02 -0700 Subject: [Pki-devel] Please review attached JSS patch . . . Message-ID: <4F6A485A.9060703@redhat.com> Although it is not just a PKI patch, this JSS patch was inspired by the work being performed on Dogtag 10: * *Bugzilla Bug #783007* -Un-deprecate previously deprecated methods in JSS 4.2.6 . . . Please review and ACK the attached patch. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jss-undo-JCA-deprecations.patch Type: text/x-patch Size: 9703 bytes Desc: not available URL: From jmagne at redhat.com Wed Mar 21 22:45:30 2012 From: jmagne at redhat.com (John Magne) Date: Wed, 21 Mar 2012 18:45:30 -0400 (EDT) Subject: [Pki-devel] Please review attached JSS patch . . . In-Reply-To: <4F6A485A.9060703@redhat.com> Message-ID: <8c6b4bf8-4ed8-484a-86f1-807660d2e143@zmail15.collab.prod.int.phx2.redhat.com> To test this did the following: 1. Loaded up the current tip into eclipse and noted how many warnings listed. 2. Built and installed the new version of JSS with this patch. 3. Refreshed eclipse pki project and did a clean. Noted approximately 72 less warnings which jibes with what Matt has reported. 4. Checked some actual files such as NetkeyKeyGenService.java from the DRM. Crypto related import statements which were previously flagged as deprecated were no longer flagged in this manner. 5. Restarted kra and did some brief testing of the UI and it was available and appeared to be working fine. ACK ----- Original Message ----- From: "Matthew Harmsen" To: pki-devel at redhat.com Sent: Wednesday, March 21, 2012 2:30:02 PM Subject: [Pki-devel] Please review attached JSS patch . . . Although it is not just a PKI patch, this JSS patch was inspired by the work being performed on Dogtag 10: ? Bugzilla Bug #783007 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . Please review and ACK the attached patch. Thanks, -- Matt _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Mar 22 01:31:20 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 21:31:20 -0400 Subject: [Pki-devel] Please review attached JSS patch . . . In-Reply-To: <8c6b4bf8-4ed8-484a-86f1-807660d2e143@zmail15.collab.prod.int.phx2.redhat.com> References: <8c6b4bf8-4ed8-484a-86f1-807660d2e143@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <1332379880.32649.3.camel@aleeredhat.laptop> Just confirmed with Jack -- thats 272 less warnings! Ade On Wed, 2012-03-21 at 18:45 -0400, John Magne wrote: > To test this did the following: > > 1. Loaded up the current tip into eclipse and noted how many warnings listed. > > 2. Built and installed the new version of JSS with this patch. > > 3. Refreshed eclipse pki project and did a clean. > > Noted approximately 72 less warnings which jibes with what Matt has reported. > > 4. Checked some actual files such as NetkeyKeyGenService.java from the DRM. > Crypto related import statements which were previously flagged as deprecated were no > longer flagged in this manner. > > 5. Restarted kra and did some brief testing of the UI and it was available and appeared to be working fine. > > > ACK > > ----- Original Message ----- > From: "Matthew Harmsen" > To: pki-devel at redhat.com > Sent: Wednesday, March 21, 2012 2:30:02 PM > Subject: [Pki-devel] Please review attached JSS patch . . . > > > Although it is not just a PKI patch, this JSS patch was inspired by the work being performed on Dogtag 10: > > > ? Bugzilla Bug #783007 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . > Please review and ACK the attached patch. > > Thanks, > -- Matt > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Thu Mar 22 02:02:42 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 19:02:42 -0700 Subject: [Pki-devel] Request to build pki-core-9.0.3-24.el6 for RHEL 6.3 in Brew . . . Message-ID: <4F6A8842.8030309@redhat.com> We would like to request an official build of 'pki-core-9.0.3-24.el6' for RHEL 6.3 in Brew to resolve the following bugs: * *Bugzilla Bug #802396* -Syntax Errors restart IPA services /var/lib/pki-ca/pki-ca: line 91 The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * pki-core-9.0.3-bz771790.patch * pki-core-9.0.3-bz745677.patch * pki-core-9.0.3-bz769388.patch * pki-core-9.0.3-bz802396.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 45515 bytes Desc: not available URL: From release-engineering at redhat.com Thu Mar 22 02:02:51 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Wed, 21 Mar 2012 22:02:51 -0400 Subject: [Pki-devel] [engineering.redhat.com #146977] Request to build pki-core-9.0.3-24.el6 for RHEL 6.3 in Brew . . . In-Reply-To: <4F6A8842.8030309@redhat.com> References: <4F6A8842.8030309@redhat.com> Message-ID: Ticket We would like to request an official build of 'pki-core-9.0.3-24.el6' for RHEL 6.3 in Brew to resolve the following bugs: * *Bugzilla Bug #802396* -Syntax Errors restart IPA services /var/lib/pki-ca/pki-ca: line 91 The official source tarball and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/pki-core/ and include the following: and include the following: * pki-core-9.0.3.tar.gz * pki-core-9.0.3-r1846.patch * pki-core-9.0.3-r1860.patch * pki-core-9.0.3-r1862.patch * pki-core-9.0.3-r1864.patch * pki-core-9.0.3-r1875.patch * pki-core-9.0.3-r1879.patch * pki-core-9.0.3-r1886.patch * pki-core-9.0.3-r1908.patch * pki-core-9.0.3-r2074.patch * pki-core-9.0.3-r2097.patch * pki-core-9.0.3-r2103.patch * pki-core-9.0.3-r2104.patch * pki-core-9.0.3-r2106.patch * pki-core-9.0.3-r2112.patch * pki-core-9.0.3-r2118.patch * pki-core-9.0.3-r2125.patch * pki-core-9.0.3-r2126.patch * pki-core-9.0.3-r2128.patch * pki-core-9.0.3-r2149.patch * pki-core-9.0.3-r2151.patch * pki-core-9.0.3-r2153.patch * pki-core-9.0.3-r2161.patch * pki-core-9.0.3-r2163.patch * pki-core-9.0.3-r2182.patch * pki-core-9.0.3-r2249.patch * pki-core-9.0.3-bz771790.patch * pki-core-9.0.3-bz745677.patch * pki-core-9.0.3-bz769388.patch * pki-core-9.0.3-bz802396.patch The updated official spec file is attached. Thanks, -- Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-core.spec Type: text/x-rpm-spec Size: 45515 bytes Desc: not available URL: From mharmsen at redhat.com Thu Mar 22 02:35:00 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 19:35:00 -0700 Subject: [Pki-devel] Request to build 'JSS 4.2.6-22.99.el5idm' on RHEL 5.9 . . . Message-ID: <4F6A8FD4.7080500@redhat.com> We would like to request official builds of 'jss-4.2.6-22.99.el5idm' on Brew per the following bugs: * Bugzilla Bug #745278 - [RFE] ECC encryption keys cannot be archived ECC phase2 work - support for ECC encryption key archival and recovery * Bugzilla Bug #797352 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . * Dogtag TRAC Task #109 (https://fedorahosted.org/pki/ticket/109) - add benign JNI jar file symbolic link from JNI libdir to JNI jar file The official spec files, source tarballs, other additional required sources, and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/jss/jss-4.2.6-22.99.el5idm/ Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From release-engineering at redhat.com Thu Mar 22 02:35:07 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Wed, 21 Mar 2012 22:35:07 -0400 Subject: [Pki-devel] [engineering.redhat.com #146982] Request to build 'JSS 4.2.6-22.99.el5idm' on RHEL 5.9 . . . In-Reply-To: <4F6A8FD4.7080500@redhat.com> References: <4F6A8FD4.7080500@redhat.com> Message-ID: Ticket We would like to request official builds of 'jss-4.2.6-22.99.el5idm' on Brew per the following bugs: * Bugzilla Bug #745278 - [RFE] ECC encryption keys cannot be archived ECC phase2 work - support for ECC encryption key archival and recovery * Bugzilla Bug #797352 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . * Dogtag TRAC Task #109 (https://fedorahosted.org/pki/ticket/109) - add benign JNI jar file symbolic link from JNI libdir to JNI jar file The official spec files, source tarballs, other additional required sources, and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/jss/jss-4.2.6-22.99.el5idm/ Thanks, -- Matt From release-engineering at redhat.com Thu Mar 22 02:59:58 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Wed, 21 Mar 2012 22:59:58 -0400 Subject: [Pki-devel] [engineering.redhat.com #146977] Request to build pki-core-9.0.3-24.el6 for RHEL 6.3 in Brew . . . In-Reply-To: <4F6A8842.8030309@redhat.com> References: <4F6A8842.8030309@redhat.com> Message-ID: Ticket done: Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4179300 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=203873 --Kevin From alee at redhat.com Thu Mar 22 03:34:11 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 23:34:11 -0400 Subject: [Pki-devel] [Patch] 0026-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch Message-ID: <1332387252.32649.8.camel@aleeredhat.laptop> As requested, I split the previous patch into two patches. One that deals with deprecations, and one with the replication issues. This is the one that deals with replications. It still includes the code to remove the clone_start_TLS code from the pkisilent components that don't really use it in any case. I also removed a few obsolete files. Please review. Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0026-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch Type: text/x-patch Size: 199002 bytes Desc: not available URL: From alee at redhat.com Thu Mar 22 03:38:01 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 23:38:01 -0400 Subject: [Pki-devel] [PATCH] 0027-Allow-clones-to-specify-master-and-replica-ports-and.patch Message-ID: <1332387481.32649.11.camel@aleeredhat.laptop> Allow clones to specify master and replica ports and security options Removed -clone_start_tls option and subsumed it into -replicationSecurity. Refactored DatabasePanel parameter verification code to allow it to be used in both update() and validate(). Added new parameters to pkisilent and databasepanel.vm. Also fixed cloning error when master uses localhost. This is the second of the split patches. It also addresses issues found by Endi in review. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0027-Allow-clones-to-specify-master-and-replica-ports-and.patch Type: text/x-patch Size: 48666 bytes Desc: not available URL: From alee at redhat.com Thu Mar 22 03:48:37 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 23:48:37 -0400 Subject: [Pki-devel] [Patch] 0026-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch In-Reply-To: <1332387252.32649.8.camel@aleeredhat.laptop> References: <1332387252.32649.8.camel@aleeredhat.laptop> Message-ID: <1332388117.32649.12.camel@aleeredhat.laptop> oops - small update. On Wed, 2012-03-21 at 23:34 -0400, Ade Lee wrote: > As requested, I split the previous patch into two patches. One that > deals with deprecations, and one with the replication issues. > > This is the one that deals with replications. It still includes the > code to remove the clone_start_TLS code from the pkisilent components > that don't really use it in any case. > > I also removed a few obsolete files. > > Please review. > Thanks, > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0026-1-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch Type: text/x-patch Size: 199870 bytes Desc: not available URL: From alee at redhat.com Thu Mar 22 03:56:33 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 23:56:33 -0400 Subject: [Pki-devel] [PATCH] 32 Replaced deprecated Date API. In-Reply-To: <4F678535.2030007@redhat.com> References: <4F678535.2030007@redhat.com> Message-ID: <1332388594.32649.13.camel@aleeredhat.laptop> ACK On Mon, 2012-03-19 at 14:12 -0500, Endi Sukma Dewata wrote: > The deprecated Date(year, month, date) constructor has been replaced > with Calendar API. There are similar Date constructors in JavaScript > but those are not deprecated and should not be replaced. > > Ticket #3 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Thu Mar 22 03:58:08 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 21 Mar 2012 23:58:08 -0400 Subject: [Pki-devel] [PATCH] 33 Removed unused SystemIdentity and SystemSigner. In-Reply-To: <4F67853A.2010203@redhat.com> References: <4F67853A.2010203@redhat.com> Message-ID: <1332388689.32649.14.camel@aleeredhat.laptop> ACK On Mon, 2012-03-19 at 14:12 -0500, Endi Sukma Dewata wrote: > The SystemIdentity and SystemSigner classes have been removed > because they are based on deprecated classes and are not used > anywhere in the code. > > Ticket #3 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Thu Mar 22 04:12:20 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 21:12:20 -0700 Subject: [Pki-devel] DOGTAG 9 builds of 'pki-core', 'pki-kra', 'pki-ocsp', and 'pki-tks' . . . Message-ID: <4F6AA6A4.3000608@redhat.com> The following builds have been respun in 'Koji' and submitted to 'Bodhi' awaiting 'Karma': * pki-core-9.0.19-1.fc15 * pki-core-9.0.19-1.fc16 * pki-core-9.0.19-1.fc17 * pki-kra-9.0.11-1.fc15 * pki-kra-9.0.11-1.fc16 * pki-kra-9.0.11-1.fc17 * pki-ocsp-9.0.10-1.fc15 * pki-ocsp-9.0.10-1.fc16 * pki-ocsp-9.0.10-1.fc17 * pki-tks-9.0.10-1.fc15 * pki-tks-9.0.10-1.fc16 * pki-tks-9.0.10-1.fc17 These resolve the following bug: * *Bugzilla Bug #802396* -Syntax Errors restart IPA services /var/lib/pki-ca/pki-ca: line 91 Basically, the location of TOMCAT_LOG was changed to match tomcat6 changes. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Thu Mar 22 04:53:19 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 21:53:19 -0700 Subject: [Pki-devel] DOGTAG 9 builds of 'pki-core', 'pki-kra', 'pki-ocsp', and 'pki-tks' . . . In-Reply-To: <4F6AA6A4.3000608@redhat.com> References: <4F6AA6A4.3000608@redhat.com> Message-ID: <4F6AB03F.50603@redhat.com> On 03/21/12 21:12, Matthew Harmsen wrote: > The following builds have been respun in 'Koji' and submitted to > 'Bodhi' awaiting 'Karma': > > * pki-core-9.0.19-1.fc15 > > * pki-core-9.0.19-1.fc16 > > * pki-core-9.0.19-1.fc17 > > * pki-kra-9.0.11-1.fc15 > > * pki-kra-9.0.11-1.fc16 > > * pki-kra-9.0.11-1.fc17 > > * pki-ocsp-9.0.10-1.fc15 > > * pki-ocsp-9.0.10-1.fc16 > > * pki-ocsp-9.0.10-1.fc17 > > * pki-tks-9.0.10-1.fc15 > > * pki-tks-9.0.10-1.fc16 > > * pki-tks-9.0.10-1.fc17 > > Packages were also built for Fedora 18 (rawhide): * pki-core-9.0.19-1.fc18 * pki-kra-9.0.11-1.fc18 * pki-ocsp-9.0.10-1.fc18 * pki-tks-9.0.10-1.fc18 > These resolve the following bug: > > * *Bugzilla Bug #802396* > -Syntax > Errors restart IPA services /var/lib/pki-ca/pki-ca: line 91 > > Basically, the location of TOMCAT_LOG was changed to match tomcat6 > changes. > > Thanks, > -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Thu Mar 22 05:02:10 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 21 Mar 2012 22:02:10 -0700 Subject: [Pki-devel] JSS builds Message-ID: <4F6AB252.8070302@redhat.com> The following builds have been respun in 'Koji' and submitted to 'Bodhi' awaiting 'Karma': * jss-4.2.6-23.fc15 * jss-4.2.6-23.fc16 * jss-4.2.6-23.fc17 Packages were also built for Fedora 18 (rawhide): * jss-4.2.6-23.fc18 These resolve the following bugs: * *Bugzilla Bug #797351* -JSS - HSM token name was mistaken for manufacturer identifier * *Bugzilla Bug #804840* -[RFE] ECC encryption keys cannot be archived * *Bugzilla Bug #783007* -Un-deprecate previously deprecated methods in JSS 4.2.6 . . . * https://fedorahosted.org/pki/ticket/85 Dogtag 10 TRAC Task #85 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . * https://fedorahosted.org/pki/ticket/109 Dogtag 10 TRAC Task #109 - Fix CMake to better handle JNI jar files Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Thu Mar 22 14:08:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 22 Mar 2012 09:08:23 -0500 Subject: [Pki-devel] [PATCH] 32 Replaced deprecated Date API. In-Reply-To: <1332388594.32649.13.camel@aleeredhat.laptop> References: <4F678535.2030007@redhat.com> <1332388594.32649.13.camel@aleeredhat.laptop> Message-ID: <4F6B3257.9080203@redhat.com> On 3/21/2012 10:56 PM, Ade Lee wrote: > ACK Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Thu Mar 22 14:08:49 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 22 Mar 2012 09:08:49 -0500 Subject: [Pki-devel] [PATCH] 33 Removed unused SystemIdentity and SystemSigner. In-Reply-To: <1332388689.32649.14.camel@aleeredhat.laptop> References: <4F67853A.2010203@redhat.com> <1332388689.32649.14.camel@aleeredhat.laptop> Message-ID: <4F6B3271.4070607@redhat.com> On 3/21/2012 10:58 PM, Ade Lee wrote: > ACK Pushed to master. Thanks. -- Endi S. Dewata From alee at redhat.com Thu Mar 22 14:25:16 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 22 Mar 2012 10:25:16 -0400 Subject: [Pki-devel] [Patch] 0026-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch References: <1332387252.32649.8.camel@aleeredhat.laptop> Message-ID: <1332426316.32307.0.camel@aleeredhat.laptop> One more small update. Forgot the cmake file list changes. Ade On Wed, 2012-03-21 at 23:48 -0400, Ade Lee wrote: > oops - small update. > > On Wed, 2012-03-21 at 23:34 -0400, Ade Lee wrote: > > As requested, I split the previous patch into two patches. One that > > deals with deprecations, and one with the replication issues. > > > > This is the one that deals with replications. It still includes the > > code to remove the clone_start_TLS code from the pkisilent components > > that don't really use it in any case. > > > > I also removed a few obsolete files. > > > > Please review. > > Thanks, > > Ade > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0026-2-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch Type: text/x-patch Size: 201396 bytes Desc: not available URL: From cfu at redhat.com Thu Mar 22 21:06:31 2012 From: cfu at redhat.com (Christina Fu) Date: Thu, 22 Mar 2012 14:06:31 -0700 Subject: [Pki-devel] Public access and archiving of Red Hat mailing lists [redhat.com #9145767] In-Reply-To: <20120322061732.E348F180560@dhcp-1-238.bne.redhat.com> References: <20120322061732.E348F180560@dhcp-1-238.bne.redhat.com> Message-ID: <4F6B9457.7030506@redhat.com> Hi Rob, Both pki-user and pki-devel are active mailing lists for subscribers. I do not see issues with people reading and archiving them. However, in the past, we have had accounts signed up and spam the aliases, for those we discovered that they don't go away just by removing them from the list, we had to ban them. If there is a better way to handle these, please advise. thanks, Christina On 03/21/2012 11:17 PM, Rob Lowe wrote: > Hi, > > My name is Rob Lowe. I work for Jay Madison in the Red Hat Information > Security team. I am contacting you in relation to a mailing list which > you own: > > pki-users > > It has been brought to our attention that an automated crawler has > subscribed the address 'archive at all-mail-archive.com' to your mailing list > for the purpose of creating a public archive at: > http://www.all-mail-archive.com/. > > Can you please review pki-users and take appropriate action, such as: > > * If the list is no longer used, please consider removing it completely > or preventing further subscriptions and posts. > > * If the list is not intended to be public, please contact > servicedesk at redhat.com and request to have it moved to an internal-only > list. List content may have already been indexed by crawlers such as > Google and may appear in search engine caches. > > Please note that removing the address 'archive at all-mail-archive.com' from > the mail list will not prevent this issue from re-occuring in the future. > > Thank you for your consideration of this request. > > Regards, > Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5130 bytes Desc: S/MIME Cryptographic Signature URL: From release-engineering at redhat.com Thu Mar 22 22:10:09 2012 From: release-engineering at redhat.com (Kevin Wright via RT) Date: Thu, 22 Mar 2012 18:10:09 -0400 Subject: [Pki-devel] [engineering.redhat.com #146982] Request to build 'JSS 4.2.6-22.99.el5idm' on RHEL 5.9 . . . In-Reply-To: <4F6A8FD4.7080500@redhat.com> References: <4F6A8FD4.7080500@redhat.com> Message-ID: Ticket done: Task Info: https://brewweb.devel.redhat.com//taskinfo?taskID=4183070 Build Info: https://brewweb.devel.redhat.com//buildinfo?buildID=204029 --Kevin From edewata at redhat.com Thu Mar 22 22:16:28 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 22 Mar 2012 17:16:28 -0500 Subject: [Pki-devel] [PATCH] 34 Removed unnecessary pki folder. Message-ID: <4F6BA4BC.8060108@redhat.com> Previously the source code was located inside a pki folder. This folder was created during svn migration and is no longer needed. This folder has now been removed and the contents have been moved up one level. Ticket #131 The patch contains only renames (and minor changes to .gitignore) so it can be applied in any order unless there's a new/deleted file. If necessary, outstanding patches can be cherry-picked on top of this patch without any problem. Eclipse project will need to be recreated in the top repo folder. The Eclipse build path might need to be updated too. Anything that calls the compose scripts will need to use the new path. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0034-Removed-unnecessary-pki-folder.patch Type: text/x-patch Size: 1686620 bytes Desc: not available URL: From alee at redhat.com Fri Mar 23 13:54:25 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 23 Mar 2012 09:54:25 -0400 Subject: [Pki-devel] [Patch] 0026-Replace-URLEncoder.encode-with-non-deprecated-form-i.patch In-Reply-To: <1332426316.32307.0.camel@aleeredhat.laptop> References: <1332387252.32649.8.camel@aleeredhat.laptop> <1332426316.32307.0.camel@aleeredhat.laptop> Message-ID: <1332510865.26024.0.camel@aleeredhat.laptop> ACKed by Endi with small changes. Pushed to master. On Thu, 2012-03-22 at 10:25 -0400, Ade Lee wrote: > One more small update. Forgot the cmake file list changes. > > Ade > > On Wed, 2012-03-21 at 23:48 -0400, Ade Lee wrote: > > oops - small update. > > > > On Wed, 2012-03-21 at 23:34 -0400, Ade Lee wrote: > > > As requested, I split the previous patch into two patches. One that > > > deals with deprecations, and one with the replication issues. > > > > > > This is the one that deals with replications. It still includes the > > > code to remove the clone_start_TLS code from the pkisilent components > > > that don't really use it in any case. > > > > > > I also removed a few obsolete files. > > > > > > Please review. > > > Thanks, > > > Ade > > > > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Fri Mar 23 14:43:17 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 23 Mar 2012 10:43:17 -0400 Subject: [Pki-devel] [PATCH] 0027-1-Allow-clones-to-specify-master-and-replica-ports-and.patch In-Reply-To: <1332387481.32649.11.camel@aleeredhat.laptop> References: <1332387481.32649.11.camel@aleeredhat.laptop> Message-ID: <1332513797.26024.3.camel@aleeredhat.laptop> Small changes from Endi's review. fixed radio button in databasepanel.vm. better default in GetConfigEntries. removed code re-adding fields in DirEnroll. Ade On Wed, 2012-03-21 at 23:38 -0400, Ade Lee wrote: > Allow clones to specify master and replica ports and security options > > Removed -clone_start_tls option and subsumed it into -replicationSecurity. > Refactored DatabasePanel parameter verification code to allow it to be > used in both update() and validate(). Added new parameters to pkisilent > and databasepanel.vm. > > Also fixed cloning error when master uses localhost. > > This is the second of the split patches. It also addresses issues found > by Endi in review. > > Please review. > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0027-1-Allow-clones-to-specify-master-and-replica-ports-and.patch Type: text/x-patch Size: 48613 bytes Desc: not available URL: From jmagne at redhat.com Fri Mar 23 17:39:40 2012 From: jmagne at redhat.com (John Magne) Date: Fri, 23 Mar 2012 13:39:40 -0400 (EDT) Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived In-Reply-To: <4F6A0FE2.7060106@redhat.com> Message-ID: Based on changes completed: ACK ----- Original Message ----- From: "Christina Fu" To: "John Magne" Cc: pki-devel at redhat.com Sent: Wednesday, March 21, 2012 10:29:06 AM Subject: Re: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived Here are the CS patches with comments rolled in. Please review: https://bugzilla.redhat.com/attachment.cgi?id=571781&action=diff&context=patch&collapsed=&headers=1&format=raw https://bugzilla.redhat.com/attachment.cgi?id=571782&action=diff&context=patch&collapsed=&headers=1&format=raw Please note that they will not be checked in until the new JSS build is ready. Also, a demo was conducted. thanks, Christina On 03/20/2012 04:40 PM, John Magne wrote: > Based on provided changes: > > Attachment #571545: jss-ECC-Phase2KeyArchivalRecovery.patch only: > > ACK > > ----- Original Message ----- > From: "Christina Fu" > To: pki-devel at redhat.com > Sent: Tuesday, March 20, 2012 3:08:33 PM > Subject: Re: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived > > > JSS part rolled in comments, please review again: > https://bugzilla.redhat.com/attachment.cgi?id=571545&action=diff&context=patch&collapsed=&headers=1&format=raw > > Note: all other CS components have dependency on the availability of this patch, so this one needs to be ack'd separately ahead of time. > > thanks, > Christina > > > On 03/19/2012 06:00 PM, Christina Fu wrote: > > On 03/19/2012 05:41 PM, John Magne wrote: > > > > Took a look at this patch for ECC support. > > Comments and questions below. > > > 1. > > KeyRecord.java line 273 > > public MetaInfo getMetaInfo() throws EBaseException { > > return mMetaInfo; > > } > > > Why does this throw the EBaseException? > All it does is return a value. > > > yes, it does not need to declare such throw of exception, even though it is the trend in that file and I was just copying them. Will change. > > > > 2. > > > CryptUtil.java line 186 > > if (sensitive == 1 ) > > keygen.sensitivePairs(true); > > else if (sensitive == 0) > > keygen.sensitivePairs(false); > > if (extractable == 1 ) > > keygen.extractablePairs(true); > > else if (extractable == 0) > > keygen.extractablePairs(false); > > > keygen.initialize(keysize); > > > > > The values extractable and sensitive are sent in as integer? > Should they be a boolean? I see the function calls have -1,-1 > for those two final params. How does not setting sensitive and > extractable different from setting them to false? > > I can see this being normal. > > As explained in the comment, the definitions are defined in JSS > pkcs11/PK11KeyPairGenerator.java, so I just followed the definition. > For your information, here is what it says in JSS: > private boolean temporaryPairMode = false; > // 1: sensitive > // 0: insensitive > // -1: sensitive if temporaryPairMode is false, > // insensitive if temporaryPairMode is true > // (the default depends on temporaryPairMode for backward > // compatibility) > private int sensitivePairMode = -1; > // 1: extractable > // 0: unextractable > // -1: unspecified (token dependent) > private int extractablePairMode = -1; > > > > > 3. > > RecoveryService.java line 363 > > > if (!isRSA) { > CMS.debug("RecoverService: recoverKey: key to recover is RSA"); > } else { > > CMS.debug("RecoverService: recoverKey: key to recover is not RSA"); > } > > Would it not be simpler to print out the value of isRSA? > > It really does not matter. A smarter question would be, why did I even > bother to have "isRSA" parameter for this method? The reason is that > there is an existing recoverKey for RSA, and the function signature does > not take return type into account so it doesn't allow polyinstantiation > of the function unless I add one more parameter to it. So I added this > isRSA param which really serves no purpose other than getting the JAVA compiler to comply. > That said, I'll change it so that it prints isRSA instead. > > > > > 4. > > EnrollmentService.java line 451 > > metaInfo.set("EllipticCurve", oidDescription); > > I think in KeyRecord.java you have a static public member variable for "EllipticCurve" > Probably should use that here for clarity. > > Will do > > > > > 5. > > ASN1Util.c line 58 > > SECItem *oid; > > Initialize to null? > > will do > > > > > 6. > > > ASN1Util.c line 78 > > oidTag = SECOID_FindOIDTag(oid); > > if (oidTag == SEC_OID_UNKNOWN) { > > JSS_throwMsg(env, INVALID_PARAMETER_EXCEPTION, > > "JSS getTagDescriptionByOid: OID UNKNOWN"); > > goto finish; > > } > > What if oidTag is null? Perhaps the call can never return this but some well known constant? > > It can't be. It was initialized to SEC_OID_UNKNOWN, and NSS returns > SEC_OID_UNKNOWN to you as well if it can't find it. > I will add comment to explain. > > > > > > 7. > > > ASN1Uti.java line 126 > > Question, it looks like the routine takes in an entire public key blob as input. > Would there be some simpler input that could end up giving us the same answer? I do not know. > There isn't any. You would have to require callers to parse down the > pubkey if we take a smaller byte array for this function. > > > > > 8. > > Also, the routine throws a InvalidBERException exception or some such. > > There are a bunch of calls to methods such as : Arrays.copyOfRange > > That method appears to throw the following exceptions: > > ArrayIndexOutOfBoundsException - > IllegalArgumentException - > NullPointerException - > > Instead of catching only an "Exception" and forcing a "InvalidBERException", would it make sense to > declare the function to also throw those exceptions? > > will do > > > 8. > > > Should we check for X509PubKeyBytes input parameter for null? > will do > > > > 9. > > > File displayBySerial.template line 103 > > if ((result.header.keyLength == null) || (result.header.keyLength<= 0)) { > > It looks like we use the above check to assume an ECC key. Is this the best way to make > this determination? Is there any info that actually tells us we have an ECC key instead of this > lack of information? > > Actually it looks like this check is used everywhere in this part of the patch when a decision is needed. > > > I wonder about that myself. I use rec.EllipticCurve != null at certain > places which worked well, but at some specific places, I couldn't for > some reason. That's why I used<=0 check. > I can try again. > > > > > > > ----- Original Message ----- > From: "Christina" > To: pki-devel at redhat.com > Sent: Wednesday, March 14, 2012 2:49:37 PM > Subject: [Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived > > > > This is the ECC phase 2 implementation (ECC key archival / recovery feature) in the JSS and DRM (KRA) > > Bug: Bug 745278 - [RFE] ECC encryption keys cannot be archived > > Please review the following patches (see "BEFORE you review" at later part of this email): > > * https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw > * https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw > * https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw > > thanks, > Christina > ============== > BEFORE you review: > > For the ECC plan and design for the different phases, please refer to http://pki.fedoraproject.org/wiki/ECC_in_Dogtag > > Note: the designs beyond phase 2 were more like a brain dump. Although I said "Do Not Review," you are free to take a peak at what's intended down the road. I will go back and take a closer look and refine/adjust the designs when I begin implementation for each new phase. > > This patch contains code for the following packages: > JSS, pki-kra, pki-common, pki-util, and pki-kra-ui > > What you need to know: > > * Problem 1 - nethsm issue: > On the server side, if you turn on FIPS mode, in addition to nethsm, you need to attach certicom as well to have ECC SSL working on the server side. This problem has already been reported to Thales last year and they said they'd look into putting the item on their next release. Recently through a different contact, we learned there might be a way to "turn it on" (still waiting for their further instruction) > > * Problem 2- Certicom issue: > This is a show-stopper. Initially, on the client side, I used Kai's special version of Xulrunner/Firefox, attached to Certicom token, so that the CRMF requests can be generated with key archival option. However, I encountered (or, re-encountered) an issue with certicom token. Certicom generates ECC keys with the wrong format (not PKCS7 conforming), which makes ECC key archival impossible on the server side if you use non-certicom token with DRM (but we expect an HSM in most product deployment). I have contacted Certicom for this issue, and they confirmed that they indeed have such issue. We are waiting for their fix. > > But then you might ask, "I thought I saw some ECC enrollment profiles/javascripts being checked in? How were the tests done?" The tests for those profiles were done against this ECC key archival/recovery DRM prototype I implemented last year (needs to be turned on manually in 8.1), where I "cheated" (yeah, that's why it's called a prototype) by decrypting the private key in the CRMF on DRM, and then manipulating the byte array to strip off the offending bytes before archival. > In the real, non-prototype implementation, which is what's in this patch, for security reasons, private keys are unwrapped directly onto the token during key archival, so there is no way to manipulate the keys in memory and bypass the Certicom issue. > > A word about Kai's special version of Xulrunner/Firefox. It is not yet publicly available. > > * Problem 3- Firefox with nethsm issue: > Another option was to connect Kai's special version firefox with an HSM to test my DRM/JSS code. However, for whatever reason, I could not get SSL going between such Firefox and ECC CA ( I did not try very hard though, as I have one other option -- writing my own ECC CRMF generation tool. I might come back to try the nethsm Firefox idea later) > > My solution (how I work on this official implementation): > * I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in current releases), gutting out the RSA part of the code, and replacing it with ECC code. I call it CRMFPopClientEC. Two types of ECC key pairs could be generated: ECDSA or ECDH (That's another benefit of writing my own tool -- I don't know if you can select which type to generate in the Javascript... maybe you can, I just don't know). I'm in no way condoning archival of signing keys!! This is just a test tool. > This tool takes a curve name as option (along with others), generates an ECC key pair, crafts up an CRMF request with key archival option, and sends request directly to the specified CA. You will see a "Deferred" message in the HTML response (see attachment for example) > Once CA agent approves the request, the archival request goes to DRM and the user private key is archived. > For recovery, DRM agent selects key recovery, etc, and you get your pkcs12. > > I did some sanity test with the pkcs12 recovered: > * Import the recovered pkcs12 into a certicom library: > pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12 > > I also tested by retrieving a p12, importing it into a browser, and adding the user as an agent and the user could act as agent via ssl client auth to the CA. > > Finally, much of the RSA-centric code had been cleared out of the way at the time when I worked on the DRM ECC prototype, so you don't see much of that in this round. > > About SELinux: > I have a set of rules generated on my system to run in enforcing mode. I do a writeup. > > For QE: > How to set up the servers? The internal wiki is at https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC . I might have given someone a copy of how to set up ECC CA to publish on fedora.org when I worked on phase1 back a couple years ago. I will put an updated copy to cover both CA and DRM when I am checking in to dogtag. > > How do you test? Well, unless you want to use my CRMFPopClientEC tool hooked up with a nethsm (like I did), or write your own tool, you can't really test it until Certicom fixes their issue. (BTW CRMFPopClientEC can also be changed to work with ceriticom, although you would run into the same issue I mentioned above) > It is not on my schedule to work on this tool; It is certainly not in production quality to be released as a regular tool. However, if you are interested in it, if we get enough request maybe we can think about doing something with it. > Other test suggestion: I did not try to clone the ECC DRM. It's a good idea to test it out. > > For techpub: > TBD > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Fri Mar 23 18:54:20 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 23 Mar 2012 13:54:20 -0500 Subject: [Pki-devel] [PATCH] 31 Removed unused variables (part 2). In-Reply-To: <4F612A19.3000503@redhat.com> References: <4F612A19.3000503@redhat.com> Message-ID: <4F6CC6DC.2040704@redhat.com> On 3/14/2012 6:30 PM, Endi Sukma Dewata wrote: > This patch brings down the warnings from 2394 to 1638. > > Ticket #103 > > http://fedorapeople.org/gitweb?p=edewata/public_git/pki.git;a=commitdiff;h=41247a58d03976150670815875f146823b5ca688 > > > It passed smoke test. Revised, rebased, ACKed by Ade. Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Fri Mar 23 19:39:28 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 23 Mar 2012 14:39:28 -0500 Subject: [Pki-devel] [PATCH] 34 Removed unnecessary pki folder. In-Reply-To: <4F6BA4BC.8060108@redhat.com> References: <4F6BA4BC.8060108@redhat.com> Message-ID: <4F6CD170.2060806@redhat.com> On 3/22/2012 5:16 PM, Endi Sukma Dewata wrote: > Previously the source code was located inside a pki folder. This folder > was created during svn migration and is no longer needed. This folder > has now been removed and the contents have been moved up one level. > > Ticket #131 > > The patch contains only renames (and minor changes to .gitignore) so it > can be applied in any order unless there's a new/deleted file. If > necessary, outstanding patches can be cherry-picked on top of this patch > without any problem. > > Eclipse project will need to be recreated in the top repo folder. The > Eclipse build path might need to be updated too. Anything that calls the > compose scripts will need to use the new path. Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0034-1-Removed-unnecessary-pki-folder.patch Type: text/x-patch Size: 1685220 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 23 19:53:25 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 23 Mar 2012 14:53:25 -0500 Subject: [Pki-devel] [PATCH] 35 Added option to build without Javadoc. Message-ID: <4F6CD4B5.5040402@redhat.com> The build scripts have been modified to provide an option to build without Javadoc to speed up development builds. The option can be used as follows: compose_pki_core_packages --without-javadoc hybrid_rpms Ticket #111 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0035-Added-option-to-build-without-Javadoc.patch Type: text/x-patch Size: 10916 bytes Desc: not available URL: From alee at redhat.com Fri Mar 23 20:34:22 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 23 Mar 2012 16:34:22 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0028-Added-policy-deprecations.patch Message-ID: <1332534863.11866.1.camel@aleeredhat.laptop> Added policy deprecations Many of the policy deprecation warnings come from classes that probably ought to be deprecated as part of the deprecated policy framework as well. Making these as deprecated removes the deprecation warnings - and we can really see where we make sure of deprecated policy code elsewhere. Also removed some URLEncoder, Decoder deprecations Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0028-Added-policy-deprecations.patch Type: text/x-patch Size: 29923 bytes Desc: not available URL: From mharmsen at redhat.com Sat Mar 24 00:39:57 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 23 Mar 2012 17:39:57 -0700 Subject: [Pki-devel] [PATCH] pki-vakwetu-0028-Added-policy-deprecations.patch In-Reply-To: <1332534863.11866.1.camel@aleeredhat.laptop> References: <1332534863.11866.1.camel@aleeredhat.laptop> Message-ID: <4F6D17DD.3030103@redhat.com> On 03/23/12 13:34, Ade Lee wrote: > Added policy deprecations > > Many of the policy deprecation warnings come from classes that probably ought to > be deprecated as part of the deprecated policy framework as well. Making these > as deprecated removes the deprecation warnings - and we can really see where > we make sure of deprecated policy code elsewhere. > > Also removed some URLEncoder, Decoder deprecations > > Please review. > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK Tested this by: * applying the patch * building and installing a fresh CA and KRA * enrolling a CA user cert * enrolling CA signing/encryption user certs which exercise the KRA * revoking a CA user cert * un-revoking a CA user cert Everything worked. Also compiled under Eclipse and saw numerous Policy deprecations (do not know how many existed prior to this patch). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Sat Mar 24 00:42:25 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 23 Mar 2012 17:42:25 -0700 Subject: [Pki-devel] [PATCH] pki-vakwetu-0028-Added-policy-deprecations.patch In-Reply-To: <4F6D17DD.3030103@redhat.com> References: <1332534863.11866.1.camel@aleeredhat.laptop> <4F6D17DD.3030103@redhat.com> Message-ID: <4F6D1871.2090005@redhat.com> On 03/23/12 17:39, Matthew Harmsen wrote: > On 03/23/12 13:34, Ade Lee wrote: >> Added policy deprecations >> >> Many of the policy deprecation warnings come from classes that probably ought to >> be deprecated as part of the deprecated policy framework as well. Making these >> as deprecated removes the deprecation warnings - and we can really see where >> we make sure of deprecated policy code elsewhere. >> >> Also removed some URLEncoder, Decoder deprecations >> >> Please review. >> Ade >> >> >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > ACK > > Tested this by: > > * applying the patch > * building and installing a fresh CA and KRA > * enrolling a CA user cert > * enrolling CA signing/encryption user certs which exercise the KRA > * revoking a CA user cert > * un-revoking a CA user cert > > Everything worked. > > Also compiled under Eclipse and saw numerous Policy deprecations (do > not know how many existed prior to this patch). > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel Alee, Although I believe that it is un-related to this bug (as I believe that I have seen this issue before), when configuring the DRM via the Browser GUI, I saw the following: Security Domain (SjcRedhat Domain) Login The Enterprise DRM Administrator will register this DRM Subsystem located at pkilinux.sjc.redhat.com under this Security Domain located at pkilinux.sjc.redhat.com. The credential information will be provided to the Security Domain for authentication. ! $errorString Uid: Password: --- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Sat Mar 24 00:54:18 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 23 Mar 2012 20:54:18 -0400 Subject: [Pki-devel] [PATCH] pki-vakwetu-0028-Added-policy-deprecations.patch In-Reply-To: <4F6D1871.2090005@redhat.com> References: <1332534863.11866.1.camel@aleeredhat.laptop> <4F6D17DD.3030103@redhat.com> <4F6D1871.2090005@redhat.com> Message-ID: <1332550459.11866.4.camel@aleeredhat.laptop> Thanks - pushed to master. There were about 950 or so warnings before this patch. Down to 563. Ade On Fri, 2012-03-23 at 17:42 -0700, Matthew Harmsen wrote: > On 03/23/12 17:39, Matthew Harmsen wrote: > > On 03/23/12 13:34, Ade Lee wrote: > > > Added policy deprecations > > > > > > Many of the policy deprecation warnings come from classes that probably ought to > > > be deprecated as part of the deprecated policy framework as well. Making these > > > as deprecated removes the deprecation warnings - and we can really see where > > > we make sure of deprecated policy code elsewhere. > > > > > > Also removed some URLEncoder, Decoder deprecations > > > > > > Please review. > > > Ade > > > > > > > > > > > > _______________________________________________ > > > Pki-devel mailing list > > > Pki-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-devel > > ACK > > > > Tested this by: > > * applying the patch > > * building and installing a fresh CA and KRA > > * enrolling a CA user cert > > * enrolling CA signing/encryption user certs which exercise > > the KRA > > * revoking a CA user cert > > * un-revoking a CA user cert > > Everything worked. > > > > Also compiled under Eclipse and saw numerous Policy deprecations (do > > not know how many existed prior to this patch). > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > Alee, > > Although I believe that it is un-related to this bug (as I believe > that I have seen this issue before), when configuring the DRM via the > Browser GUI, I saw the following: > Security Domain (SjcRedhat Domain) Login > > The Enterprise DRM Administrator will register this DRM > Subsystem located at pkilinux.sjc.redhat.com under this > Security Domain located at pkilinux.sjc.redhat.com. The > credential information will be provided to the Security Domain > for authentication. > > ! $errorString > > Uid: > Password: > --- Matt From mharmsen at redhat.com Sat Mar 24 01:30:02 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 23 Mar 2012 18:30:02 -0700 Subject: [Pki-devel] [PATCH] 34 Removed unnecessary pki folder. In-Reply-To: <4F6CD170.2060806@redhat.com> References: <4F6BA4BC.8060108@redhat.com> <4F6CD170.2060806@redhat.com> Message-ID: <4F6D239A.2010400@redhat.com> On 03/23/12 12:39, Endi Sukma Dewata wrote: > On 3/22/2012 5:16 PM, Endi Sukma Dewata wrote: >> Previously the source code was located inside a pki folder. This folder >> was created during svn migration and is no longer needed. This folder >> has now been removed and the contents have been moved up one level. >> >> Ticket #131 >> >> The patch contains only renames (and minor changes to .gitignore) so it >> can be applied in any order unless there's a new/deleted file. If >> necessary, outstanding patches can be cherry-picked on top of this patch >> without any problem. >> >> Eclipse project will need to be recreated in the top repo folder. The >> Eclipse build path might need to be updated too. Anything that calls the >> compose scripts will need to use the new path. > > Rebased. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK I updated the following two pki.fedoraproject.org Wiki pages to comply with this change: * http://pki.fedoraproject.org/wiki/PKI_Open_Source_History (formally check-outs were done to 'pkigit' rather than 'pki') * http://pki.fedoraproject.org/wiki/Hosting_a_Developmental_PKI_%27git%27_Repository_on_%27fedorapeople.org%27 (formally check-outs were done to 'pki.git' rather than 'pki') -------------- next part -------------- An HTML attachment was scrubbed... URL: From mharmsen at redhat.com Sat Mar 24 01:48:03 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 23 Mar 2012 18:48:03 -0700 Subject: [Pki-devel] [PATCH] 35 Added option to build without Javadoc. In-Reply-To: <4F6CD4B5.5040402@redhat.com> References: <4F6CD4B5.5040402@redhat.com> Message-ID: <4F6D27D3.9040001@redhat.com> On 03/23/12 12:53, Endi Sukma Dewata wrote: > The build scripts have been modified to provide an option to build > without Javadoc to speed up development builds. The option can be > used as follows: > > compose_pki_core_packages --without-javadoc hybrid_rpms > > Ticket #111 > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel CONDITIONAL ACK with CAVEATS: The following invocations succeeded building the RPMS without building the javadoc RPMS (it should have failed with a Usage message): * pki/scripts/compose_pki_core_packages *--w* hybrid_rpms * pki/scripts/compose_pki_core_packages *--without* hybrid_rpms (note that '*--without*' was used instead of '*--without-javadoc*') while the following invocations failed as expected and issued a Usage message: * pki/scripts/compose_pki_core_packages *--foo* hybrid_rpms * pki/scripts/compose_pki_core_packages *--without-foo* hybrid_rpms * pki/scripts/compose_pki_core_packages *--without-javadocs* hybrid_rpms (note that '*--without-javadocs*' (plural) was used instead of '*--without-javadoc*') *Please feel free to check-in this patch once this issue has been corrected.* Although I think that it is un-necessary to change code nor necessarily document this, the '*--without-javadoc*' option is /*ONLY*/ useful for building the '*pki-core*' component (no other '*compose*' scripts generate any 'javadoc' packages, and certain packages such as 'pki-tps' will NEVER generate javadocs as this is a non-java component). Additionally, this option would only be utilized when building 'RPMS' (e. g. - 'rpms', 'hybrid_rpms', and/or 'patched_rpms'; it is completely ignored when building 'srpm', 'hybrid_srpm', and/or 'patched_srpm') regardless of component. However, I don't think that invocation necessarily needs to fail which building SRPMS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Sun Mar 25 17:20:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 25 Mar 2012 12:20:01 -0500 Subject: [Pki-devel] [PATCH] 34 Removed unnecessary pki folder. In-Reply-To: <4F6D239A.2010400@redhat.com> References: <4F6BA4BC.8060108@redhat.com> <4F6CD170.2060806@redhat.com> <4F6D239A.2010400@redhat.com> Message-ID: <4F6F53C1.2090104@redhat.com> On 3/23/2012 8:30 PM, Matthew Harmsen wrote: > ACK > > I updated the following two pki.fedoraproject.org Wiki pages to comply > with this change: > > * http://pki.fedoraproject.org/wiki/PKI_Open_Source_History (formally > check-outs were done to 'pkigit' rather than 'pki') > * http://pki.fedoraproject.org/wiki/Hosting_a_Developmental_PKI_%27git%27_Repository_on_%27fedorapeople.org%27 > (formally check-outs were done to 'pki.git' rather than 'pki') Thanks. The patches for each git branch that we have (Dogtag 10, Dogtag 9 and IPA v2 RHEL 6 Errata) are available here: http://edewata.fedorapeople.org/patches/pki/ -- Endi S. Dewata From edewata at redhat.com Mon Mar 26 15:41:45 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Mar 2012 10:41:45 -0500 Subject: [Pki-devel] [PATCH] 35 Added option to build without Javadoc. In-Reply-To: <4F6D27D3.9040001@redhat.com> References: <4F6CD4B5.5040402@redhat.com> <4F6D27D3.9040001@redhat.com> Message-ID: <4F708E39.3000009@redhat.com> On 3/23/2012 8:48 PM, Matthew Harmsen wrote: > On 03/23/12 12:53, Endi Sukma Dewata wrote: >> The build scripts have been modified to provide an option to build >> without Javadoc to speed up development builds. The option can be >> used as follows: >> >> compose_pki_core_packages --without-javadoc hybrid_rpms >> >> Ticket #111 > CONDITIONAL ACK with CAVEATS: > > The following invocations succeeded building the RPMS without building > the javadoc RPMS (it should have failed with a Usage message): > > * pki/scripts/compose_pki_core_packages *--w* hybrid_rpms > * pki/scripts/compose_pki_core_packages *--without* hybrid_rpms (note > that '*--without*' was used instead of '*--without-javadoc*') > > while the following invocations failed as expected and issued a Usage > message: > > * pki/scripts/compose_pki_core_packages *--foo* hybrid_rpms > * pki/scripts/compose_pki_core_packages *--without-foo* hybrid_rpms > * pki/scripts/compose_pki_core_packages *--without-javadocs* > hybrid_rpms (note that '*--without-javadocs*' (plural) was used > instead of '*--without-javadoc*') > > *Please feel free to check-in this patch once this issue has been > corrected.* It seems to be a feature of the getopt. According to getopt man page: Long options may be abbreviated, as long as the abbreviation is not ambiguous. There's already a request to allow disabling abbreviation, but it won't be fixed: http://sourceware.org/bugzilla/show_bug.cgi?id=6863 I've tested adding another option (e.g. --without-test). If you specify an abbreviated option (e.g. --without) it will find the first defined option that matches it (e.g. --without-javadoc) even thought it could be considered ambiguous. -- Endi S. Dewata From mharmsen at redhat.com Mon Mar 26 16:28:50 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 26 Mar 2012 09:28:50 -0700 Subject: [Pki-devel] [PATCH] 35 Added option to build without Javadoc. In-Reply-To: <4F708E39.3000009@redhat.com> References: <4F6CD4B5.5040402@redhat.com> <4F6D27D3.9040001@redhat.com> <4F708E39.3000009@redhat.com> Message-ID: <4F709942.3030104@redhat.com> On 03/26/12 08:41, Endi Sukma Dewata wrote: > On 3/23/2012 8:48 PM, Matthew Harmsen wrote: >> On 03/23/12 12:53, Endi Sukma Dewata wrote: >>> The build scripts have been modified to provide an option to build >>> without Javadoc to speed up development builds. The option can be >>> used as follows: >>> >>> compose_pki_core_packages --without-javadoc hybrid_rpms >>> >>> Ticket #111 > >> CONDITIONAL ACK with CAVEATS: >> >> The following invocations succeeded building the RPMS without building >> the javadoc RPMS (it should have failed with a Usage message): >> >> * pki/scripts/compose_pki_core_packages *--w* hybrid_rpms >> * pki/scripts/compose_pki_core_packages *--without* hybrid_rpms (note >> that '*--without*' was used instead of '*--without-javadoc*') >> >> while the following invocations failed as expected and issued a Usage >> message: >> >> * pki/scripts/compose_pki_core_packages *--foo* hybrid_rpms >> * pki/scripts/compose_pki_core_packages *--without-foo* hybrid_rpms >> * pki/scripts/compose_pki_core_packages *--without-javadocs* >> hybrid_rpms (note that '*--without-javadocs*' (plural) was used >> instead of '*--without-javadoc*') >> >> *Please feel free to check-in this patch once this issue has been >> corrected.* > > It seems to be a feature of the getopt. According to getopt man page: > > Long options may be abbreviated, as long as the abbreviation is > not ambiguous. > > There's already a request to allow disabling abbreviation, but it > won't be fixed: > > http://sourceware.org/bugzilla/show_bug.cgi?id=6863 > > I've tested adding another option (e.g. --without-test). If you > specify an abbreviated option (e.g. --without) it will find the first > defined option that matches it (e.g. --without-javadoc) even thought > it could be considered ambiguous. > okay -- looks like there is no intention to fix this. Go ahead and check this in. -- Matt From edewata at redhat.com Mon Mar 26 18:09:49 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Mar 2012 13:09:49 -0500 Subject: [Pki-devel] [PATCH] 34 Removed unnecessary pki folder. In-Reply-To: <4F6F53C1.2090104@redhat.com> References: <4F6BA4BC.8060108@redhat.com> <4F6CD170.2060806@redhat.com> <4F6D239A.2010400@redhat.com> <4F6F53C1.2090104@redhat.com> Message-ID: <4F70B0ED.1010503@redhat.com> On 3/25/2012 12:20 PM, Endi Sukma Dewata wrote: > On 3/23/2012 8:30 PM, Matthew Harmsen wrote: >> ACK >> >> I updated the following two pki.fedoraproject.org Wiki pages to comply >> with this change: >> >> * http://pki.fedoraproject.org/wiki/PKI_Open_Source_History (formally >> check-outs were done to 'pkigit' rather than 'pki') >> * >> http://pki.fedoraproject.org/wiki/Hosting_a_Developmental_PKI_%27git%27_Repository_on_%27fedorapeople.org%27 >> >> (formally check-outs were done to 'pki.git' rather than 'pki') > > Thanks. The patches for each git branch that we have (Dogtag 10, Dogtag > 9 and IPA v2 RHEL 6 Errata) are available here: > > http://edewata.fedorapeople.org/patches/pki/ Pushed the Dogtag 10 patch to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Mon Mar 26 18:11:22 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Mar 2012 13:11:22 -0500 Subject: [Pki-devel] [PATCH] 35 Added option to build without Javadoc. In-Reply-To: <4F709942.3030104@redhat.com> References: <4F6CD4B5.5040402@redhat.com> <4F6D27D3.9040001@redhat.com> <4F708E39.3000009@redhat.com> <4F709942.3030104@redhat.com> Message-ID: <4F70B14A.7020702@redhat.com> On 3/26/2012 11:28 AM, Matthew Harmsen wrote: >> It seems to be a feature of the getopt. According to getopt man page: >> >> Long options may be abbreviated, as long as the abbreviation is >> not ambiguous. >> >> There's already a request to allow disabling abbreviation, but it >> won't be fixed: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=6863 >> >> I've tested adding another option (e.g. --without-test). If you >> specify an abbreviated option (e.g. --without) it will find the first >> defined option that matches it (e.g. --without-javadoc) even thought >> it could be considered ambiguous. >> > okay -- looks like there is no intention to fix this. > > Go ahead and check this in. Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Mon Mar 26 22:48:24 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 26 Mar 2012 17:48:24 -0500 Subject: [Pki-devel] [PATCH] 36 Replaced deprecated XMLSerializer. Message-ID: <4F70F238.50704@redhat.com> The deprecated XMLSerializer has been replaced with LSSerializer. The new API does not provide a way to control the indentation or line width. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0036-Replaced-deprecated-XMLSerializer.patch Type: text/x-patch Size: 6042 bytes Desc: not available URL: From alee at redhat.com Tue Mar 27 13:57:09 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 27 Mar 2012 09:57:09 -0400 Subject: [Pki-devel] [PATCH] 36 Replaced deprecated XMLSerializer. In-Reply-To: <4F70F238.50704@redhat.com> References: <4F70F238.50704@redhat.com> Message-ID: <1332856630.23930.1.camel@aleeredhat.laptop> This change seems innocuous enough. Just to be sure though, please install IPA using the new pkisilent just to confirm that the installation has not been broken. Assuming all is OK, ACK. On Mon, 2012-03-26 at 17:48 -0500, Endi Sukma Dewata wrote: > The deprecated XMLSerializer has been replaced with LSSerializer. > The new API does not provide a way to control the indentation or > line width. > > Ticket #3 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Mar 27 21:38:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Mar 2012 16:38:41 -0500 Subject: [Pki-devel] [PATCH] 36 Replaced deprecated XMLSerializer. In-Reply-To: <1332856630.23930.1.camel@aleeredhat.laptop> References: <4F70F238.50704@redhat.com> <1332856630.23930.1.camel@aleeredhat.laptop> Message-ID: <4F723361.3040205@redhat.com> On 3/27/2012 8:57 AM, Ade Lee wrote: > This change seems innocuous enough. Just to be sure though, please > install IPA using the new pkisilent just to confirm that the > installation has not been broken. > > Assuming all is OK, ACK. Yes, it has been tested with pkisilent. Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Tue Mar 27 22:20:17 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Mar 2012 17:20:17 -0500 Subject: [Pki-devel] [PATCH] 37 Replaced Candlepin with RESTEasy. Message-ID: <4F723D21.4020503@redhat.com> Previously the code depends on the old RESTEasy libraries provided by Candlepin package. Now the Eclipse classpath, build/setup scripts, and the spec file have been updated to use the libraries provided by the new RESTEasy package. Ticket #29 Note: The new RESTEasy package is only available in F17. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0037-Replaced-Candlepin-with-RESTEasy.patch Type: text/x-patch Size: 45839 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 01:57:42 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Mar 2012 20:57:42 -0500 Subject: [Pki-devel] [PATCH] 37 Replaced Candlepin with RESTEasy. In-Reply-To: <4F723D21.4020503@redhat.com> References: <4F723D21.4020503@redhat.com> Message-ID: <4F727016.3080305@redhat.com> On 3/27/2012 5:20 PM, Endi Sukma Dewata wrote: > Previously the code depends on the old RESTEasy libraries provided by > Candlepin package. Now the Eclipse classpath, build/setup scripts, and > the spec file have been updated to use the libraries provided by the > new RESTEasy package. > > Ticket #29 > > Note: The new RESTEasy package is only available in F17. Rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0037-1-Replaced-Candlepin-with-RESTEasy.patch Type: text/x-patch Size: 45924 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 01:57:56 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Mar 2012 20:57:56 -0500 Subject: [Pki-devel] [PATCH] 28 Added CMSException. In-Reply-To: <4F5132DC.9010106@redhat.com> References: <4F5132DC.9010106@redhat.com> Message-ID: <4F727024.1080601@redhat.com> On 3/2/2012 2:51 PM, Endi Sukma Dewata wrote: > The CMSException was added to simplify error handling in REST services. > The exception may include an error message and some other attributes. > When the server throws a CMSException (or its subclass), the exception > will be marshalled into XML and unmarshalled by the client, then thrown > again as a new exception which can be caught by the application. > > Ticket #100 > > Note: This patch depends on patch #25-1. This patch also requires > RESTEasy 2.3.2 jar files to be installed under /usr/share/java/resteasy. > Might need to wait for ticket #29. Rebased on top of patch #37-1. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0028-1-Added-CMSException.patch Type: text/x-patch Size: 28479 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 13:39:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 08:39:01 -0500 Subject: [Pki-devel] [PATCH] 37 Replaced Candlepin with RESTEasy. In-Reply-To: <4F727016.3080305@redhat.com> References: <4F723D21.4020503@redhat.com> <4F727016.3080305@redhat.com> Message-ID: <4F731475.7090505@redhat.com> On 3/27/2012 8:57 PM, Endi Sukma Dewata wrote: > On 3/27/2012 5:20 PM, Endi Sukma Dewata wrote: >> Previously the code depends on the old RESTEasy libraries provided by >> Candlepin package. Now the Eclipse classpath, build/setup scripts, and >> the spec file have been updated to use the libraries provided by the >> new RESTEasy package. >> >> Ticket #29 >> >> Note: The new RESTEasy package is only available in F17. > > Rebased. I revised the patch such that in older Fedora it will not require the new RESTEasy package. Instead, you can download RESTEasy 2.3.2 (must be this version) zip file, install it somewhere, and create the following symlinks to mimic F17: /usr/share/java/glassfish-jaxb/jaxb-impl.jar /usr/share/java/resteasy/jaxrs-api.jar /usr/share/java/resteasy/resteasy-jaxb-provider.jar /usr/share/java/resteasy/resteasy-jaxrs.jar /usr/share/java/resteasy/resteasy-jettison-provider.jar /usr/share/java/scannotation.jar This way we can continue the development on F16 without having to officially support it. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0037-2-Replaced-Candlepin-with-RESTEasy.patch Type: text/x-patch Size: 47824 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 13:39:27 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 08:39:27 -0500 Subject: [Pki-devel] [PATCH] 28 Added CMSException. In-Reply-To: <4F727024.1080601@redhat.com> References: <4F5132DC.9010106@redhat.com> <4F727024.1080601@redhat.com> Message-ID: <4F73148F.50606@redhat.com> On 3/27/2012 8:57 PM, Endi Sukma Dewata wrote: > On 3/2/2012 2:51 PM, Endi Sukma Dewata wrote: >> The CMSException was added to simplify error handling in REST services. >> The exception may include an error message and some other attributes. >> When the server throws a CMSException (or its subclass), the exception >> will be marshalled into XML and unmarshalled by the client, then thrown >> again as a new exception which can be caught by the application. >> >> Ticket #100 >> >> Note: This patch depends on patch #25-1. This patch also requires >> RESTEasy 2.3.2 jar files to be installed under /usr/share/java/resteasy. >> Might need to wait for ticket #29. > > Rebased on top of patch #37-1. Rebased on top of patch #37-2. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0028-2-Added-CMSException.patch Type: text/x-patch Size: 37737 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 15:36:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 10:36:23 -0500 Subject: [Pki-devel] [PATCH] 28 Added CMSException. In-Reply-To: <4F73148F.50606@redhat.com> References: <4F5132DC.9010106@redhat.com> <4F727024.1080601@redhat.com> <4F73148F.50606@redhat.com> Message-ID: <4F732FF7.7060300@redhat.com> On 3/28/2012 8:39 AM, Endi Sukma Dewata wrote: > On 3/27/2012 8:57 PM, Endi Sukma Dewata wrote: >> On 3/2/2012 2:51 PM, Endi Sukma Dewata wrote: >>> The CMSException was added to simplify error handling in REST services. >>> The exception may include an error message and some other attributes. >>> When the server throws a CMSException (or its subclass), the exception >>> will be marshalled into XML and unmarshalled by the client, then thrown >>> again as a new exception which can be caught by the application. >>> >>> Ticket #100 >>> >>> Note: This patch depends on patch #25-1. This patch also requires >>> RESTEasy 2.3.2 jar files to be installed under /usr/share/java/resteasy. >>> Might need to wait for ticket #29. >> >> Rebased on top of patch #37-1. > > Rebased on top of patch #37-2. Revised the patch to use jar files from standard packages: httpcomponents-client httpcomponents-core jakarta-commons-httpclient -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0028-3-Added-CMSException.patch Type: text/x-patch Size: 38197 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 15:38:20 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 10:38:20 -0500 Subject: [Pki-devel] [PATCH] 38-43 Replaced deprecated code. Message-ID: <4F73306C.3030402@redhat.com> Attached are some patches to replace deprecated code. The patches may contain some other code cleanup because my Eclipse is configured to remove white spaces and unnecessary type casting automatically on save. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0038-Replaced-deprecated-DataInputStream.readLine.patch Type: text/x-patch Size: 10341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0039-Replaced-deprecated-JPasswordField.getText.patch Type: text/x-patch Size: 1413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0040-Replaced-deprecated-Dialog.show.patch Type: text/x-patch Size: 3123 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0041-Replaced-deprecated-ApacheHttpClientExecutor.patch Type: text/x-patch Size: 4440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0042-Replaced-deprecated-JTable.createScrollPaneForTable.patch Type: text/x-patch Size: 1316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0043-Replaced-deprecated-AlgorithmId.getAlgorithmId.patch Type: text/x-patch Size: 45516 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 18:24:55 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 13:24:55 -0500 Subject: [Pki-devel] [PATCH] 38-43 Replaced deprecated code. In-Reply-To: <4F73306C.3030402@redhat.com> References: <4F73306C.3030402@redhat.com> Message-ID: <4F735777.4010906@redhat.com> On 3/28/2012 10:38 AM, Endi Sukma Dewata wrote: > Attached are some patches to replace deprecated code. The patches may > contain some other code cleanup because my Eclipse is configured to > remove white spaces and unnecessary type casting automatically on save. > > Ticket #3 ACKed by Ade. Pushed everything to master except #41 because it depends on #28-3. -- Endi S. Dewata From edewata at redhat.com Wed Mar 28 19:29:02 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 14:29:02 -0500 Subject: [Pki-devel] [PATCH] 44 Replaced deprecated LDAPConnection.authenticate(). Message-ID: <4F73667E.5040907@redhat.com> The deprecated authenticate() method in LDAPConnection has been replaced with another authenticate() method with different signature. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0044-Replaced-deprecated-LDAPConnection.authenticate.patch Type: text/x-patch Size: 3367 bytes Desc: not available URL: From edewata at redhat.com Wed Mar 28 19:29:17 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 28 Mar 2012 14:29:17 -0500 Subject: [Pki-devel] [PATCH] 45 Replaced key status update thread with executor service. Message-ID: <4F73668D.60004@redhat.com> The Thread.stop() is deprecated, so the key status update thread is now implemented with executor service to allow stopping the task gracefully. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0045-Replaced-key-status-update-thread-with-executor-serv.patch Type: text/x-patch Size: 14648 bytes Desc: not available URL: From alee at redhat.com Thu Mar 29 02:58:04 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 28 Mar 2012 22:58:04 -0400 Subject: [Pki-devel] [PATCH] 37 Replaced Candlepin with RESTEasy. In-Reply-To: <4F731475.7090505@redhat.com> References: <4F723D21.4020503@redhat.com> <4F727016.3080305@redhat.com> <4F731475.7090505@redhat.com> Message-ID: <1332989884.5245.3.camel@aleeredhat.laptop> Works for me. I was able to build and create/configure a CA ad KRA on f17 and on f15 (using the workaround steps). On f15, I found that creating the symlinks below allowed me to build, but that the pki instances failed to follow the symlinks to start up. When I physically copied the jars to the right locations , rather than creating symlinks, everything worked fine. ACK. On Wed, 2012-03-28 at 08:39 -0500, Endi Sukma Dewata wrote: > On 3/27/2012 8:57 PM, Endi Sukma Dewata wrote: > > On 3/27/2012 5:20 PM, Endi Sukma Dewata wrote: > >> Previously the code depends on the old RESTEasy libraries provided by > >> Candlepin package. Now the Eclipse classpath, build/setup scripts, and > >> the spec file have been updated to use the libraries provided by the > >> new RESTEasy package. > >> > >> Ticket #29 > >> > >> Note: The new RESTEasy package is only available in F17. > > > > Rebased. > > I revised the patch such that in older Fedora it will not require the > new RESTEasy package. Instead, you can download RESTEasy 2.3.2 (must be > this version) zip file, install it somewhere, and create the following > symlinks to mimic F17: > > /usr/share/java/glassfish-jaxb/jaxb-impl.jar > /usr/share/java/resteasy/jaxrs-api.jar > /usr/share/java/resteasy/resteasy-jaxb-provider.jar > /usr/share/java/resteasy/resteasy-jaxrs.jar > /usr/share/java/resteasy/resteasy-jettison-provider.jar > /usr/share/java/scannotation.jar > > This way we can continue the development on F16 without having to > officially support it. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Thu Mar 29 16:20:52 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 29 Mar 2012 11:20:52 -0500 Subject: [Pki-devel] [PATCH] 46 Replaced deprecated LDAPVirtualListResponse.parseResponse(). Message-ID: <4F748BE4.9020207@redhat.com> The VLV control can be obtained directly from the list of response controls by checking its type. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0046-Replaced-deprecated-LDAPVirtualListResponse.parseRes.patch Type: text/x-patch Size: 7305 bytes Desc: not available URL: From edewata at redhat.com Thu Mar 29 16:20:55 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 29 Mar 2012 11:20:55 -0500 Subject: [Pki-devel] [PATCH] 47 Replaced deprecated RevRequest constructor. Message-ID: <4F748BE7.5000709@redhat.com> The deprecated RevRequest constructor has been replaced with another constructor with null invalidity date. Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0047-Replaced-deprecated-RevRequest-constructor.patch Type: text/x-patch Size: 3812 bytes Desc: not available URL: From edewata at redhat.com Thu Mar 29 16:21:01 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 29 Mar 2012 11:21:01 -0500 Subject: [Pki-devel] [PATCH] 48 Replaced deprecated PK11PubKey.fromRaw(). Message-ID: <4F748BED.4060104@redhat.com> The deprecated fromRaw() method in PK11PubKey has been replaced with fromSPKI(). Ticket #3 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0048-Replaced-deprecated-PK11PubKey.fromRaw.patch Type: text/x-patch Size: 19445 bytes Desc: not available URL: From edewata at redhat.com Thu Mar 29 19:36:58 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 29 Mar 2012 14:36:58 -0500 Subject: [Pki-devel] [PATCH] 37 Replaced Candlepin with RESTEasy. In-Reply-To: <1332989884.5245.3.camel@aleeredhat.laptop> References: <4F723D21.4020503@redhat.com> <4F727016.3080305@redhat.com> <4F731475.7090505@redhat.com> <1332989884.5245.3.camel@aleeredhat.laptop> Message-ID: <4F74B9DA.50802@redhat.com> On 3/28/2012 9:58 PM, Ade Lee wrote: > Works for me. > > I was able to build and create/configure a CA ad KRA on f17 and on f15 > (using the workaround steps). > > On f15, I found that creating the symlinks below allowed me to build, > but that the pki instances failed to follow the symlinks to start up. > When I physically copied the jars to the right locations , rather than > creating symlinks, everything worked fine. > > ACK. Pushed to master. Thanks. -- Endi S. Dewata From edewata at redhat.com Thu Mar 29 21:06:26 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 29 Mar 2012 16:06:26 -0500 Subject: [Pki-devel] [PATCH] 28 Added CMSException. In-Reply-To: <4F732FF7.7060300@redhat.com> References: <4F5132DC.9010106@redhat.com> <4F727024.1080601@redhat.com> <4F73148F.50606@redhat.com> <4F732FF7.7060300@redhat.com> Message-ID: <4F74CED2.1030009@redhat.com> On 3/28/2012 10:36 AM, Endi Sukma Dewata wrote: > On 3/28/2012 8:39 AM, Endi Sukma Dewata wrote: >> On 3/27/2012 8:57 PM, Endi Sukma Dewata wrote: >>> On 3/2/2012 2:51 PM, Endi Sukma Dewata wrote: >>>> The CMSException was added to simplify error handling in REST services. >>>> The exception may include an error message and some other attributes. >>>> When the server throws a CMSException (or its subclass), the exception >>>> will be marshalled into XML and unmarshalled by the client, then thrown >>>> again as a new exception which can be caught by the application. >>>> >>>> Ticket #100 >>>> >>>> Note: This patch depends on patch #25-1. This patch also requires >>>> RESTEasy 2.3.2 jar files to be installed under >>>> /usr/share/java/resteasy. >>>> Might need to wait for ticket #29. >>> >>> Rebased on top of patch #37-1. >> >> Rebased on top of patch #37-2. > > Revised the patch to use jar files from standard packages: > httpcomponents-client > httpcomponents-core > jakarta-commons-httpclient Per Ade's feedback I added a way to specify the HTTP response code in the exception. The client will intercept responses with code 4xx and 5xx and convert it back into exception. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0028-4-Added-CMSException.patch Type: text/x-patch Size: 40962 bytes Desc: not available URL: From edewata at redhat.com Fri Mar 30 17:31:07 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 30 Mar 2012 12:31:07 -0500 Subject: [Pki-devel] [PATCH] 44 Replaced deprecated LDAPConnection.authenticate(). In-Reply-To: <4F73667E.5040907@redhat.com> References: <4F73667E.5040907@redhat.com> Message-ID: <4F75EDDB.5030709@redhat.com> On 3/28/2012 2:29 PM, Endi Sukma Dewata wrote: > The deprecated authenticate() method in LDAPConnection has been > replaced with another authenticate() method with different signature. > > Ticket #3 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Mar 30 17:31:26 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 30 Mar 2012 12:31:26 -0500 Subject: [Pki-devel] [PATCH] 47 Replaced deprecated RevRequest constructor. In-Reply-To: <4F748BE7.5000709@redhat.com> References: <4F748BE7.5000709@redhat.com> Message-ID: <4F75EDEE.9010303@redhat.com> On 3/29/2012 11:20 AM, Endi Sukma Dewata wrote: > The deprecated RevRequest constructor has been replaced with > another constructor with null invalidity date. > > Ticket #3 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Mar 30 17:31:49 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 30 Mar 2012 12:31:49 -0500 Subject: [Pki-devel] [PATCH] 48 Replaced deprecated PK11PubKey.fromRaw(). In-Reply-To: <4F748BED.4060104@redhat.com> References: <4F748BED.4060104@redhat.com> Message-ID: <4F75EE05.2070203@redhat.com> On 3/29/2012 11:21 AM, Endi Sukma Dewata wrote: > The deprecated fromRaw() method in PK11PubKey has been replaced > with fromSPKI(). > > Ticket #3 ACKed by Ade. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Mar 30 21:58:26 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 30 Mar 2012 16:58:26 -0500 Subject: [Pki-devel] [PATCH] 28 Added CMSException. In-Reply-To: <4F732FF7.7060300@redhat.com> References: <4F5132DC.9010106@redhat.com> <4F727024.1080601@redhat.com> <4F73148F.50606@redhat.com> <4F732FF7.7060300@redhat.com> Message-ID: <4F762C82.1020200@redhat.com> On 3/28/2012 10:36 AM, Endi Sukma Dewata wrote: > On 3/28/2012 8:39 AM, Endi Sukma Dewata wrote: >> On 3/27/2012 8:57 PM, Endi Sukma Dewata wrote: >>> On 3/2/2012 2:51 PM, Endi Sukma Dewata wrote: >>>> The CMSException was added to simplify error handling in REST services. >>>> The exception may include an error message and some other attributes. >>>> When the server throws a CMSException (or its subclass), the exception >>>> will be marshalled into XML and unmarshalled by the client, then thrown >>>> again as a new exception which can be caught by the application. >>>> >>>> Ticket #100 >>>> >>>> Note: This patch depends on patch #25-1. This patch also requires >>>> RESTEasy 2.3.2 jar files to be installed under >>>> /usr/share/java/resteasy. >>>> Might need to wait for ticket #29. >>> >>> Rebased on top of patch #37-1. >> >> Rebased on top of patch #37-2. > > Revised the patch to use jar files from standard packages: > httpcomponents-client > httpcomponents-core > jakarta-commons-httpclient ACKed by Ade. Pushed to master. Additional work may be needed to convert other WebApplicationExceptions to CMSExceptions. -- Endi S. Dewata From edewata at redhat.com Fri Mar 30 21:58:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 30 Mar 2012 16:58:57 -0500 Subject: [Pki-devel] [PATCH] 38-43 Replaced deprecated code. In-Reply-To: <4F735777.4010906@redhat.com> References: <4F73306C.3030402@redhat.com> <4F735777.4010906@redhat.com> Message-ID: <4F762CA1.4000000@redhat.com> On 3/28/2012 1:24 PM, Endi Sukma Dewata wrote: > On 3/28/2012 10:38 AM, Endi Sukma Dewata wrote: >> Attached are some patches to replace deprecated code. The patches may >> contain some other code cleanup because my Eclipse is configured to >> remove white spaces and unnecessary type casting automatically on save. >> >> Ticket #3 > > ACKed by Ade. Pushed everything to master except #41 because it depends > on #28-3. Pushed #41 to master. -- Endi S. Dewata From mharmsen at redhat.com Sat Mar 31 00:25:05 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 30 Mar 2012 17:25:05 -0700 Subject: [Pki-devel] Please review attached JSS patch (one more class that needed to be un-deprecated) . . . Message-ID: <4F764EE1.4050503@redhat.com> Although it is not just a PKI patch, this JSS patch was inspired by the work being performed on Dogtag 10: * *Bugzilla Bug #783007* -Un-deprecate previously deprecated methods in JSS 4.2.6 . . . Please review the latest patch which un-deprecates BadPaddingException, and ACK the attached patch. Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jss-undo-BadPaddingException-deprecation.patch Type: text/x-patch Size: 679 bytes Desc: not available URL: From jmagne at redhat.com Sat Mar 31 00:47:03 2012 From: jmagne at redhat.com (John Magne) Date: Fri, 30 Mar 2012 20:47:03 -0400 (EDT) Subject: [Pki-devel] Please review attached JSS patch (one more class that needed to be un-deprecated) . . . In-Reply-To: <4F764EE1.4050503@redhat.com> Message-ID: <9eb36721-bc07-4d24-a790-cb6368cc97fc@zmail15.collab.prod.int.phx2.redhat.com> ACK ----- Original Message ----- From: "Matthew Harmsen" To: pki-devel at redhat.com Sent: Friday, March 30, 2012 5:25:05 PM Subject: [Pki-devel] Please review attached JSS patch (one more class that needed to be un-deprecated) . . . Although it is not just a PKI patch, this JSS patch was inspired by the work being performed on Dogtag 10: ? Bugzilla Bug #783007 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . Please review the latest patch which un-deprecates BadPaddingException, and ACK the attached patch. Thanks, -- Matt _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Sat Mar 31 01:29:28 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 30 Mar 2012 18:29:28 -0700 Subject: [Pki-devel] Request to build 'JSS 4.2.6-23.99.el5idm' on RHEL 5.9 . . . Message-ID: <4F765DF8.1040204@redhat.com> We would like to request official builds of 'jss-4.2.6-22.99.el5idm' on Brew per the following bugs: * Bugzilla Bug #797352 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . BadPaddingException The official spec files, source tarballs, other additional required sources, and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/jss/jss-4.2.6-23.99.el5idm/ Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From release-engineering at redhat.com Sat Mar 31 01:29:35 2012 From: release-engineering at redhat.com (mharmsen@redhat.com via RT) Date: Fri, 30 Mar 2012 21:29:35 -0400 Subject: [Pki-devel] [engineering.redhat.com #148088] Request to build 'JSS 4.2.6-23.99.el5idm' on RHEL 5.9 . . . In-Reply-To: <4F765DF8.1040204@redhat.com> References: <4F765DF8.1040204@redhat.com> Message-ID: Ticket We would like to request official builds of 'jss-4.2.6-22.99.el5idm' on Brew per the following bugs: * Bugzilla Bug #797352 - Un-deprecate previously deprecated methods in JSS 4.2.6 . . . BadPaddingException The official spec files, source tarballs, other additional required sources, and all associated patches are located at: * http://pki.fedoraproject.org/pki/sources/jss/jss-4.2.6-23.99.el5idm/ Thanks, -- Matt