From edewata at redhat.com Sat Dec 1 05:44:13 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Fri, 30 Nov 2012 23:44:13 -0600
Subject: [Pki-devel] [PATCH] 184 I18n for ProfileList.template.
In-Reply-To: <50A3A960.5040104@redhat.com>
References: <50A3A960.5040104@redhat.com>
Message-ID: <50B9992D.8020403@redhat.com>
On 11/14/2012 8:23 AM, Endi Sukma Dewata wrote:
> The messages in ProfileList.template in CA EE has been extracted
> into a properties file which can be translated separately.
>
> The original messages in the template have been marked as follows:
> ...message...
>
> When the page is loaded into the browser, the original message will
> be replaced with the translated message.
>
> Ticket #406
Just to clarify, this patch demonstrates how message customization could
be done. A full solution will require many incremental patches due to
the number of messages to be customized. Here is how it works.
Previously a theme consist of HTML/Velocity templates, JS files, images
and CSS files. The HTML/Velocity templates contain HTML code, JS code,
paths to images/CSS files, and text messages.
To create a custom theme we had to clone the default Dogtag theme, then
customize the files as needed. Most of the time we'll only be changing
the images, CSS, and messages, but we still have to duplicate everything
in the theme. This becomes a maintenance issue because if we change
anything in the default theme, the custom theme will not be updated
automatically, and it could be hard to merge the changes.
Recently we've been moving the templates and JS files out of the theme
packages into the core packages because they are less likely to be
changed, leaving just the images and CSS files in the theme. However,
the messages are still part of the templates. To support customization
we need to separate the messages from the templates.
JQuery and jquery-i18n-properties are tools that we can use to load
custom messages from a separate properties file and then replace the
original messages in the template.
Suppose we have a template which contains the following HTML code:
Dogtag |
The Dogtag Certificate System is an enterprise-class open
source Certificate Authority.
|
To make the messages customizable we need to mark them. Here we are
using a which shouldn't be visible in the browser:
Dogtag
|
The Dogtag Certificate
System is an enterprise-class open source Certificate
Authority.
|
The element is assigned a class "message" which will be used to
locate all messages. The element is also assigned a name which will be
used as message key. The original message itself is left intact within
the to help visualize the page. Then we create a
Messages.properties that maps the message keys to the actual messages:
title = Dogtag
description = The Dogtag Certificate System is an enterprise-class\
open source Certificate Authority.
The messages in the properties file can be customized as needed. Then
we'll use the tools to load the custom messages and replace the original
messages in the template:
$.i18n.properties({
name: 'Messages',
...
callback: function() {
var key;
for (key in $.i18n.map) {
var message = $.i18n.prop(key);
$('span.message[name='+key+']').html(message);
}
}
});
After the browser finishes loading the page the $.i18n.properties() will
run to load the custom messages from Messages.properties. Once they are
loaded the callback() will run to replace all marked messages with the
custom messages.
There are 2 different purposes for message customization which require
different strategies: branding and translation.
If we're doing branding only, like the current implementation, we need
to use separate properties for each theme, for example:
Messages.properties - Dogtag theme
Messages.properties - Other theme
If we're doing translation only we need to use separate properties file
for each language, for example:
Messages.properties - Dogtag theme in English
Messages_es.properties - Dogtag theme in Spanish
Messages_fr.properties - Dogtag theme in French
If we're doing both branding and translation the number of files will be
multiplied:
Messages.properties - Dogtag theme in English
Messages_es.properties - Dogtag theme in Spanish
Messages_fr.properties - Dogtag theme in French
Messages.properties - Other theme in English
Messages_es.properties - Other theme in Spanish
Messages_fr.properties - Other theme in French
One possible solution is to do the translation and branding separately
using different message markers:
Dogtag
|
The Dogtag Certificate
System is an enterprise-class open source Certificate
Authority.
|
Here we can load the translated "message" first, then load the
untranslated "product" after that. This solution doesn't require as many
properties files:
Messages.properties - English messages
Messages_es.properties - Spanish messages
Messages_fr.properties - French messages
Product.properties - Dogtag theme
Product.properties - Other theme
If we can assume the messages are fixed, we can actually include the
messages in the core packages and leave the branding in the theme packages.
We could also stack the theme files, similar to the sections in the
configuration file, so the custom theme only needs to store the files
that are different from the default theme. This will require the ability
to install multiple themes and deploy the custom theme on top of the
default theme.
--
Endi S. Dewata
From edewata at redhat.com Mon Dec 3 02:55:57 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Sun, 02 Dec 2012 20:55:57 -0600
Subject: [Pki-devel] [PATCH] 190 Reorganized TPS templates and scripts.
In-Reply-To: <1354255161.2654.24.camel@aleeredhat.laptop>
References: <50B53B6F.7020906@redhat.com>
<1354255161.2654.24.camel@aleeredhat.laptop>
Message-ID: <50BC14BD.2010709@redhat.com>
On 11/29/2012 11:59 PM, Ade Lee wrote:
> Looks good - and is the right idea. What makes you think that cfg.pl is
> not used? There are functions that are defined there that are used in
> the esc cgi scripts.
>
> Please restore cfg.pl.
As discussed on IRC, there are 2 cfg.pl files, one in the TPS core page
and the other in the TPS theme package. In the original code before the
patch, the code in pkicreate:2064 copies the cfg.pl in theme to override
the cfg.pl in core:
return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path,
$default_dir_permissions, $default_file_permissions,
$pki_user, $pki_group);
So the original cfg.pl in core package was never actually used.
In the updated #192 this code no longer exists since the TPS theme has
being removed.
--
Endi S. Dewata
From edewata at redhat.com Mon Dec 3 02:56:00 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Sun, 02 Dec 2012 20:56:00 -0600
Subject: [Pki-devel] [PATCH] 191 Reorganized TPS CSS files.
In-Reply-To: <1354255334.2654.27.camel@aleeredhat.laptop>
References: <50B53B74.6050305@redhat.com>
<1354255334.2654.27.camel@aleeredhat.laptop>
Message-ID: <50BC14C0.5080002@redhat.com>
On 11/30/2012 12:02 AM, Ade Lee wrote:
> Looks good in general.
>
> I noticed that you moved dogtag/tps-ui/shared/docroot/esc/style.css ->
> dogtag/common-ui/shared/style.css instead of
> dogtag/common-ui/shared/esc/style.css. Why is this?
This was an error. It has been fixed in the attached revised patch.
--
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0191-1-Reorganized-TPS-CSS-files.patch
Type: text/x-patch
Size: 23708 bytes
Desc: not available
URL:
From edewata at redhat.com Mon Dec 3 02:56:05 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Sun, 02 Dec 2012 20:56:05 -0600
Subject: [Pki-devel] [PATCH] 192 Removed RA and TPS theme packages.
In-Reply-To: <1354256740.2654.40.camel@aleeredhat.laptop>
References: <50B53B79.5090003@redhat.com>
<1354256740.2654.40.camel@aleeredhat.laptop>
Message-ID: <50BC14C5.30109@redhat.com>
On 11/30/2012 12:25 AM, Ade Lee wrote:
> 1. There are cgi scripts which are explicitly set to have execute
> permissions by the build script. Is this not needed? Can you confirm
> this?
Are you referring to the removal of this code?
chmod 755 %{buildroot}%{_datadir}/pki/tps-ui/cgi-bin/sow/cfg.pl
There are codes in pkicreate:2076-2090 that set the permissions:
set_permissions("${cgibin_instance_path}/sow/*.pl",
$default_exe_permissions);
So the above chmod code is not necessary.
> 2. As mentioned in a previous review, cfg.pl is needed.
This is discussed in my response for #190.
> 3. Are there really no changes required in pkicreate and pkiremove?
> Surely there must be code that copies stuff from /usr/share/pki/tps-ui
> and /usr/share/pki/ra-ui. There may even be a programmatic check for
> the ui package. And don't we need code to copy the relevant bits from
> common-ui?
The original code already has some codes to copy the subsystem theme
files and common theme files (see pkicreate:2064):
# Copy /usr/share/pki/-ui to
return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path,
$default_dir_permissions, $default_file_permissions,
$pki_user, $pki_group);
# Copy /usr/share/pki/common-ui to /docroot/pki
return 0 if !copy_directory(
$common_ui_subsystem_path,
"$docroot_instance_path/pki",
$default_dir_permissions, $default_file_permissions,
$pki_user, $pki_group);
In the attached revised patch the code to copy -ui has been
removed because the RA/TPS themes don't exist anymore. The
copy_directory() would ignore missing folders, but it's better to remove
unused code.
The code to copy the common-ui is left intact.
> 4. How was this tested? Do you pkicreate and configure RA and TPS
> instances?
Yes, the UI seems to be working fine, I didn't see any broken
page/links/images, but I'm not familiar with these subsystems to test
the functionality.
> When the instances are created, are all the relevant files
> where you expect them to be ?-- ie. compare the layout of old/new
> instances.
Yes, they seem to be deployed to the same locations.
> Did you configure the instances and check the UI to make sure it looks
> the same?
Yes, they looked fine.
> Did you look at the security officer workstation stuff ?
> Or configure a token?
No, I'm not familiar with this UI, please let me know how to test it.
--
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0192-1-Removed-RA-and-TPS-theme-packages.patch
Type: text/x-patch
Size: 8974 bytes
Desc: not available
URL:
From alee at redhat.com Mon Dec 3 14:13:39 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 03 Dec 2012 09:13:39 -0500
Subject: [Pki-devel] [PATCH] 93, 94 - changes for a common admin user
In-Reply-To: <1354312886.2317.18.camel@aleeredhat.laptop>
References: <1354226974.2654.8.camel@aleeredhat.laptop>
<50B8D721.30000@redhat.com>
<1354312886.2317.18.camel@aleeredhat.laptop>
Message-ID: <1354544020.2317.19.camel@aleeredhat.laptop>
Changes made as discussed. Pushed to master.
On Fri, 2012-11-30 at 17:01 -0500, Ade Lee wrote:
> On Fri, 2012-11-30 at 09:56 -0600, Endi Sukma Dewata wrote:
> > Some issues:
> >
> > 1. The pki_use_common_admin_user is set to true in [Common] but
> > overwritten to false in [CA]:
> >
> > [Common]
> > pki_use_common_admin_user=true
> >
> > [CA]
> > pki_use_common_admin_user=false
> >
> > If I understood correctly it's done this way to make sure that if we use
> > a common admin user, only CA will generate the certificate file, but not
> > the other subsystems:
> >
> > if not config.str2bool(master['pki_clone']) and \
> > not config.str2bool(master['pki_use_common_admin_user']):
> >
> > ... create cert file ...
> >
> > Having conflicting pki_use_common_admin_users in the same config file is
> > confusing to users because we are actually using a common admin user for
> > all subsystems including CA so the value should be "true". I think it
> > would be better to check for CA explicitly in the code:
> >
> > [Common]
> > pki_use_common_admin_user=true
> >
> > if not config.str2bool(master['pki_clone']):
> > if not config.str2bool(master['pki_use_common_admin_user']) or
> > master['pki_subsystem'] == 'CA':
> >
> > ... create cert file ...
> >
>
> The thing is - someone might install a subordinate CA and want to use
> this mechanism to import an admin cert. So we dont really want to
> exclude this simply because its a CA. Maybe we can change the name of
> the directive to import_admin_cert = true/false ? This makes it clearer
> what we are doing. Sound reasonable?
>
> > 2. The location of the admin cert was changed from pki_client_dir to
> > pki_database_path. I think we should keep it in pki_client_dir because
> > the certificate belongs to the admin, not the instance, so it should be
> > in the admin's home directory. As long as the other subsystems are
> > created by the same admin the code should be able to read the cert from
> > the admin's home directory.
> >
> > So the following parameters should point to the admin's home directory:
> > - pki_client_admin_cert_p12
> > - pki_admin_cert_file
> >
> I agree with you that the cert belongs to the admin and not the
> instance. The problem is that we purge the client database by default.
> And we should purge it once we have generated the p12 file, because it
> includes the nss database and password files and so on. I suppose we
> could be a little smarter about exactly what it is that we purge.
>
> > 3. The default pki_admin_nickname is too long:
> >
> > PKI Administrator's example.com Security Domain ID
> >
> > It can be simplified without losing information:
> >
> > PKI Administrator of example.com
>
> OK - will change.
> >
> > 4. The common cert files are called ca_admin.*. I think we should remove
> > the "ca_" to reflect that the cert works on all subsystems.
> >
> Well along the lines of my response to above, if we change the name of
> the directive to import_admin_cert - then its clearer that we are
> importing a cert that was generated during the CA install for the admin
> user on all subsystems.
>
> In that case, using ca_admin is probably OK.
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Mon Dec 3 15:36:27 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 03 Dec 2012 10:36:27 -0500
Subject: [Pki-devel] [PATCH] 190 Reorganized TPS templates and scripts.
In-Reply-To: <50BC14BD.2010709@redhat.com>
References: <50B53B6F.7020906@redhat.com>
<1354255161.2654.24.camel@aleeredhat.laptop>
<50BC14BD.2010709@redhat.com>
Message-ID: <1354548988.2317.22.camel@aleeredhat.laptop>
On Sun, 2012-12-02 at 20:55 -0600, Endi Sukma Dewata wrote:
> On 11/29/2012 11:59 PM, Ade Lee wrote:
> > Looks good - and is the right idea. What makes you think that cfg.pl is
> > not used? There are functions that are defined there that are used in
> > the esc cgi scripts.
> >
> > Please restore cfg.pl.
>
> As discussed on IRC, there are 2 cfg.pl files, one in the TPS core page
> and the other in the TPS theme package. In the original code before the
> patch, the code in pkicreate:2064 copies the cfg.pl in theme to override
> the cfg.pl in core:
>
> return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path,
> $default_dir_permissions, $default_file_permissions,
> $pki_user, $pki_group);
>
> So the original cfg.pl in core package was never actually used.
>
> In the updated #192 this code no longer exists since the TPS theme has
> being removed.
>
ACK.
Whats troubling is that neither version appears to be correct. The
correct version is in the 8.1 branch. We don't have to fix this here.
You can commit your patch, but please open a ticket to fix the security
officer workstation cgi scripts in dogtag 10.
From alee at redhat.com Mon Dec 3 15:36:50 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 03 Dec 2012 10:36:50 -0500
Subject: [Pki-devel] [PATCH] 191 Reorganized TPS CSS files.
In-Reply-To: <50BC14C0.5080002@redhat.com>
References: <50B53B74.6050305@redhat.com>
<1354255334.2654.27.camel@aleeredhat.laptop>
<50BC14C0.5080002@redhat.com>
Message-ID: <1354549010.2317.23.camel@aleeredhat.laptop>
ACK
On Sun, 2012-12-02 at 20:56 -0600, Endi Sukma Dewata wrote:
> On 11/30/2012 12:02 AM, Ade Lee wrote:
> > Looks good in general.
> >
> > I noticed that you moved dogtag/tps-ui/shared/docroot/esc/style.css ->
> > dogtag/common-ui/shared/style.css instead of
> > dogtag/common-ui/shared/esc/style.css. Why is this?
>
> This was an error. It has been fixed in the attached revised patch.
>
From alee at redhat.com Mon Dec 3 15:38:16 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 03 Dec 2012 10:38:16 -0500
Subject: [Pki-devel] [PATCH] 192 Removed RA and TPS theme packages.
In-Reply-To: <50BC14C5.30109@redhat.com>
References: <50B53B79.5090003@redhat.com>
<1354256740.2654.40.camel@aleeredhat.laptop>
<50BC14C5.30109@redhat.com>
Message-ID: <1354549097.2317.25.camel@aleeredhat.laptop>
On Sun, 2012-12-02 at 20:56 -0600, Endi Sukma Dewata wrote:
> On 11/30/2012 12:25 AM, Ade Lee wrote:
> > 1. There are cgi scripts which are explicitly set to have execute
> > permissions by the build script. Is this not needed? Can you confirm
> > this?
>
> Are you referring to the removal of this code?
>
> chmod 755 %{buildroot}%{_datadir}/pki/tps-ui/cgi-bin/sow/cfg.pl
>
> There are codes in pkicreate:2076-2090 that set the permissions:
>
> set_permissions("${cgibin_instance_path}/sow/*.pl",
> $default_exe_permissions);
>
> So the above chmod code is not necessary.
>
> > 2. As mentioned in a previous review, cfg.pl is needed.
>
> This is discussed in my response for #190.
>
> > 3. Are there really no changes required in pkicreate and pkiremove?
> > Surely there must be code that copies stuff from /usr/share/pki/tps-ui
> > and /usr/share/pki/ra-ui. There may even be a programmatic check for
> > the ui package. And don't we need code to copy the relevant bits from
> > common-ui?
>
> The original code already has some codes to copy the subsystem theme
> files and common theme files (see pkicreate:2064):
>
> # Copy /usr/share/pki/-ui to
> return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path,
> $default_dir_permissions, $default_file_permissions,
> $pki_user, $pki_group);
>
> # Copy /usr/share/pki/common-ui to /docroot/pki
> return 0 if !copy_directory(
> $common_ui_subsystem_path,
> "$docroot_instance_path/pki",
> $default_dir_permissions, $default_file_permissions,
> $pki_user, $pki_group);
>
> In the attached revised patch the code to copy -ui has been
> removed because the RA/TPS themes don't exist anymore. The
> copy_directory() would ignore missing folders, but it's better to remove
> unused code.
>
> The code to copy the common-ui is left intact.
>
> > 4. How was this tested? Do you pkicreate and configure RA and TPS
> > instances?
>
> Yes, the UI seems to be working fine, I didn't see any broken
> page/links/images, but I'm not familiar with these subsystems to test
> the functionality.
>
> > When the instances are created, are all the relevant files
> > where you expect them to be ?-- ie. compare the layout of old/new
> > instances.
>
> Yes, they seem to be deployed to the same locations.
>
> > Did you configure the instances and check the UI to make sure it looks
> > the same?
>
> Yes, they looked fine.
>
> > Did you look at the security officer workstation stuff ?
> > Or configure a token?
>
> No, I'm not familiar with this UI, please let me know how to test it.
>
As noted for the other patch, the Security Officer workstation is
probably broken (for reasons not related to your patch).
ACK.
From alee at redhat.com Mon Dec 3 16:38:42 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 03 Dec 2012 11:38:42 -0500
Subject: [Pki-devel] [PATCH] 184 I18n for ProfileList.template.
In-Reply-To: <50B9992D.8020403@redhat.com>
References: <50A3A960.5040104@redhat.com> <50B9992D.8020403@redhat.com>
Message-ID: <1354552723.2317.27.camel@aleeredhat.laptop>
Great explanation. thanks!
Lets use the latest jquery -- and find out a little more about any
license requirements.
ACK.
Ade
On Fri, 2012-11-30 at 23:44 -0600, Endi Sukma Dewata wrote:
> On 11/14/2012 8:23 AM, Endi Sukma Dewata wrote:
> > The messages in ProfileList.template in CA EE has been extracted
> > into a properties file which can be translated separately.
> >
> > The original messages in the template have been marked as follows:
> > ...message...
> >
> > When the page is loaded into the browser, the original message will
> > be replaced with the translated message.
> >
> > Ticket #406
>
> Just to clarify, this patch demonstrates how message customization could
> be done. A full solution will require many incremental patches due to
> the number of messages to be customized. Here is how it works.
>
> Previously a theme consist of HTML/Velocity templates, JS files, images
> and CSS files. The HTML/Velocity templates contain HTML code, JS code,
> paths to images/CSS files, and text messages.
>
> To create a custom theme we had to clone the default Dogtag theme, then
> customize the files as needed. Most of the time we'll only be changing
> the images, CSS, and messages, but we still have to duplicate everything
> in the theme. This becomes a maintenance issue because if we change
> anything in the default theme, the custom theme will not be updated
> automatically, and it could be hard to merge the changes.
>
> Recently we've been moving the templates and JS files out of the theme
> packages into the core packages because they are less likely to be
> changed, leaving just the images and CSS files in the theme. However,
> the messages are still part of the templates. To support customization
> we need to separate the messages from the templates.
>
> JQuery and jquery-i18n-properties are tools that we can use to load
> custom messages from a separate properties file and then replace the
> original messages in the template.
>
> Suppose we have a template which contains the following HTML code:
>
>
> Dogtag |
>
> The Dogtag Certificate System is an enterprise-class open
> source Certificate Authority.
> |
>
>
> To make the messages customizable we need to mark them. Here we are
> using a which shouldn't be visible in the browser:
>
>
>
> Dogtag
> |
>
> The Dogtag Certificate
> System is an enterprise-class open source Certificate
> Authority.
> |
>
>
> The element is assigned a class "message" which will be used to
> locate all messages. The element is also assigned a name which will be
> used as message key. The original message itself is left intact within
> the to help visualize the page. Then we create a
> Messages.properties that maps the message keys to the actual messages:
>
> title = Dogtag
> description = The Dogtag Certificate System is an enterprise-class\
> open source Certificate Authority.
>
> The messages in the properties file can be customized as needed. Then
> we'll use the tools to load the custom messages and replace the original
> messages in the template:
>
> $.i18n.properties({
> name: 'Messages',
> ...
> callback: function() {
> var key;
> for (key in $.i18n.map) {
> var message = $.i18n.prop(key);
> $('span.message[name='+key+']').html(message);
> }
> }
> });
>
> After the browser finishes loading the page the $.i18n.properties() will
> run to load the custom messages from Messages.properties. Once they are
> loaded the callback() will run to replace all marked messages with the
> custom messages.
>
> There are 2 different purposes for message customization which require
> different strategies: branding and translation.
>
> If we're doing branding only, like the current implementation, we need
> to use separate properties for each theme, for example:
>
> Messages.properties - Dogtag theme
> Messages.properties - Other theme
>
> If we're doing translation only we need to use separate properties file
> for each language, for example:
>
> Messages.properties - Dogtag theme in English
> Messages_es.properties - Dogtag theme in Spanish
> Messages_fr.properties - Dogtag theme in French
>
> If we're doing both branding and translation the number of files will be
> multiplied:
>
> Messages.properties - Dogtag theme in English
> Messages_es.properties - Dogtag theme in Spanish
> Messages_fr.properties - Dogtag theme in French
>
> Messages.properties - Other theme in English
> Messages_es.properties - Other theme in Spanish
> Messages_fr.properties - Other theme in French
>
> One possible solution is to do the translation and branding separately
> using different message markers:
>
>
>
> Dogtag
> |
>
> The class="product" name="long_title">Dogtag Certificate
> System is an enterprise-class open source Certificate
> Authority.
> |
>
>
> Here we can load the translated "message" first, then load the
> untranslated "product" after that. This solution doesn't require as many
> properties files:
>
> Messages.properties - English messages
> Messages_es.properties - Spanish messages
> Messages_fr.properties - French messages
>
> Product.properties - Dogtag theme
> Product.properties - Other theme
>
> If we can assume the messages are fixed, we can actually include the
> messages in the core packages and leave the branding in the theme packages.
>
> We could also stack the theme files, similar to the sections in the
> configuration file, so the custom theme only needs to store the files
> that are different from the default theme. This will require the ability
> to install multiple themes and deploy the custom theme on top of the
> default theme.
>
From edewata at redhat.com Mon Dec 3 17:05:39 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 03 Dec 2012 11:05:39 -0600
Subject: [Pki-devel] [PATCH] 189 Reorganized RA templates and scripts.
In-Reply-To: <1354255028.2654.22.camel@aleeredhat.laptop>
References: <50B53B68.1010404@redhat.com>
<1354255028.2654.22.camel@aleeredhat.laptop>
Message-ID: <50BCDBE3.9060101@redhat.com>
On 11/29/2012 11:57 PM, Ade Lee wrote:
> ACK, but please check in once all the changes in patches 189 - 192 are
> verified.
Pushed to master.
--
Endi S. Dewata
From edewata at redhat.com Mon Dec 3 17:05:49 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 03 Dec 2012 11:05:49 -0600
Subject: [Pki-devel] [PATCH] 190 Reorganized TPS templates and scripts.
In-Reply-To: <1354548988.2317.22.camel@aleeredhat.laptop>
References: <50B53B6F.7020906@redhat.com>
<1354255161.2654.24.camel@aleeredhat.laptop>
<50BC14BD.2010709@redhat.com>
<1354548988.2317.22.camel@aleeredhat.laptop>
Message-ID: <50BCDBED.4080307@redhat.com>
On 12/3/2012 9:36 AM, Ade Lee wrote:
> ACK.
>
> Whats troubling is that neither version appears to be correct. The
> correct version is in the 8.1 branch. We don't have to fix this here.
> You can commit your patch, but please open a ticket to fix the security
> officer workstation cgi scripts in dogtag 10.
Pushed to master. Ticket for SOW:
https://fedorahosted.org/pki/ticket/429
--
Endi S. Dewata
From edewata at redhat.com Mon Dec 3 17:05:53 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 03 Dec 2012 11:05:53 -0600
Subject: [Pki-devel] [PATCH] 191 Reorganized TPS CSS files.
In-Reply-To: <1354549010.2317.23.camel@aleeredhat.laptop>
References: <50B53B74.6050305@redhat.com>
<1354255334.2654.27.camel@aleeredhat.laptop>
<50BC14C0.5080002@redhat.com>
<1354549010.2317.23.camel@aleeredhat.laptop>
Message-ID: <50BCDBF1.6040908@redhat.com>
On 12/3/2012 9:36 AM, Ade Lee wrote:
> ACK
Pushed to master.
--
Endi S. Dewata
From edewata at redhat.com Mon Dec 3 17:05:57 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 03 Dec 2012 11:05:57 -0600
Subject: [Pki-devel] [PATCH] 192 Removed RA and TPS theme packages.
In-Reply-To: <1354549097.2317.25.camel@aleeredhat.laptop>
References: <50B53B79.5090003@redhat.com>
<1354256740.2654.40.camel@aleeredhat.laptop>
<50BC14C5.30109@redhat.com>
<1354549097.2317.25.camel@aleeredhat.laptop>
Message-ID: <50BCDBF5.7010804@redhat.com>
On 12/3/2012 9:38 AM, Ade Lee wrote:
> ACK.
Pushed to master.
--
Endi S. Dewata
From edewata at redhat.com Mon Dec 3 17:06:03 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Mon, 03 Dec 2012 11:06:03 -0600
Subject: [Pki-devel] [PATCH] 184 I18n for ProfileList.template.
In-Reply-To: <1354552723.2317.27.camel@aleeredhat.laptop>
References: <50A3A960.5040104@redhat.com> <50B9992D.8020403@redhat.com>
<1354552723.2317.27.camel@aleeredhat.laptop>
Message-ID: <50BCDBFB.509@redhat.com>
On 12/3/2012 10:38 AM, Ade Lee wrote:
> ACK.
Pushed to master.
--
Endi S. Dewata
From nkinder at redhat.com Tue Dec 4 04:25:34 2012
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 03 Dec 2012 20:25:34 -0800
Subject: [Pki-devel] [PATCH] 1 Run restorecon on top-level log directory
Message-ID: <50BD7B3E.1050303@redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-nkinder-0001-Run-restorecon-on-top-level-log-directory.patch
Type: text/x-patch
Size: 1383 bytes
Desc: not available
URL:
From alee at redhat.com Tue Dec 4 07:32:56 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 02:32:56 -0500
Subject: [Pki-devel] [PATCH] 95 use interpolation to build default parameters
Message-ID: <1354606377.2317.30.camel@aleeredhat.laptop>
Use interpolation to build default parameters
This patch replaces the code in pkiparser with defaults that are
built up using ConfigParser interpolation. The patch gets most
(but not all) default parameters.
Please review.
Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0095-Use-interpolation-to-build-default-parameters.patch
Type: text/x-patch
Size: 67250 bytes
Desc: not available
URL:
From alee at redhat.com Tue Dec 4 16:43:56 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 11:43:56 -0500
Subject: [Pki-devel] [PATCH] 96 corrections for interpolation review
Message-ID: <1354639437.2317.32.camel@aleeredhat.laptop>
Please review.
Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0096-Interpolation-correction-patch-based-on-review-comme.patch
Type: text/x-patch
Size: 16104 bytes
Desc: not available
URL:
From alee at redhat.com Tue Dec 4 17:13:15 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 12:13:15 -0500
Subject: [Pki-devel] [PATCH] 95 use interpolation to build default
parameters
In-Reply-To: <1354606377.2317.30.camel@aleeredhat.laptop>
References: <1354606377.2317.30.camel@aleeredhat.laptop>
Message-ID: <1354641196.2317.33.camel@aleeredhat.laptop>
acked by Endi. Pushed to master.
On Tue, 2012-12-04 at 02:32 -0500, Ade Lee wrote:
> Use interpolation to build default parameters
>
> This patch replaces the code in pkiparser with defaults that are
> built up using ConfigParser interpolation. The patch gets most
> (but not all) default parameters.
>
> Please review.
>
> Ade
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Tue Dec 4 17:19:05 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 12:19:05 -0500
Subject: [Pki-devel] [PATCH] 96 corrections for interpolation review
In-Reply-To: <1354639437.2317.32.camel@aleeredhat.laptop>
References: <1354639437.2317.32.camel@aleeredhat.laptop>
Message-ID: <1354641546.29745.0.camel@aleeredhat.laptop>
acked by Endi. Pushed to master.
On Tue, 2012-12-04 at 11:43 -0500, Ade Lee wrote:
> Please review.
>
> Ade
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From edewata at redhat.com Tue Dec 4 18:23:41 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Tue, 04 Dec 2012 12:23:41 -0600
Subject: [Pki-devel] [PATCH] 197 Archiving default deployment configuration.
Message-ID: <50BE3FAD.9010707@redhat.com>
The default deployment configuration has been renamed and moved to
/etc/pki/default.cfg to make it more accessible to users. The pkispawn
has been modified to archive the default deployment configuration
along with the user-provided configuration in the registry. The
pkidestroy will now use both archived configuration files to ensure
proper removal of the subsystem.
Ticket #399
--
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0197-Archiving-default-deployment-configuration.patch
Type: text/x-patch
Size: 37659 bytes
Desc: not available
URL:
From alee at redhat.com Tue Dec 4 20:27:35 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 15:27:35 -0500
Subject: [Pki-devel] [PATCH] 197 Archiving default deployment
configuration.
In-Reply-To: <50BE3FAD.9010707@redhat.com>
References: <50BE3FAD.9010707@redhat.com>
Message-ID: <1354652856.29745.2.camel@aleeredhat.laptop>
ack
On Tue, 2012-12-04 at 12:23 -0600, Endi Sukma Dewata wrote:
> The default deployment configuration has been renamed and moved to
> /etc/pki/default.cfg to make it more accessible to users. The pkispawn
> has been modified to archive the default deployment configuration
> along with the user-provided configuration in the registry. The
> pkidestroy will now use both archived configuration files to ensure
> proper removal of the subsystem.
>
> Ticket #399
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Tue Dec 4 20:26:20 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 15:26:20 -0500
Subject: [Pki-devel] [PATCH] 1 Run restorecon on top-level log directory
In-Reply-To: <50BD7B3E.1050303@redhat.com>
References: <50BD7B3E.1050303@redhat.com>
Message-ID: <1354652781.29745.1.camel@aleeredhat.laptop>
ACK - pushed to master.
On Mon, 2012-12-03 at 20:25 -0800, Nathan Kinder wrote:
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Tue Dec 4 20:51:50 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 04 Dec 2012 15:51:50 -0500
Subject: [Pki-devel] [PATCH] 197 Archiving default deployment
configuration.
In-Reply-To: <1354652856.29745.2.camel@aleeredhat.laptop>
References: <50BE3FAD.9010707@redhat.com>
<1354652856.29745.2.camel@aleeredhat.laptop>
Message-ID: <1354654311.29745.3.camel@aleeredhat.laptop>
pushed to master
On Tue, 2012-12-04 at 15:27 -0500, Ade Lee wrote:
> ack
>
> On Tue, 2012-12-04 at 12:23 -0600, Endi Sukma Dewata wrote:
> > The default deployment configuration has been renamed and moved to
> > /etc/pki/default.cfg to make it more accessible to users. The pkispawn
> > has been modified to archive the default deployment configuration
> > along with the user-provided configuration in the registry. The
> > pkidestroy will now use both archived configuration files to ensure
> > proper removal of the subsystem.
> >
> > Ticket #399
> >
> > _______________________________________________
> > 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 Wed Dec 5 06:31:44 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 04 Dec 2012 22:31:44 -0800
Subject: [Pki-devel] [PATCH] Implemented ability to use an external CA
Message-ID: <50BEEA50.9080108@redhat.com>
The attached patch addresses the following PKI issues:
* TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle
external CA
This code has been successfully tested on a slightly earlier version of
the source tree, although the attached patch has been re-based to the
'master'.
To test this code, the following procedure was followed on an x86_64
machine running 64-bit Fedora 18:
* First, a standard CA was created to be used as an "External CA"
using the following command and file ('# mv typescript
typescript.external' once finished):
o script -c 'pkispawn -s CA -f /tmp/pki/external.cfg -vvv'
# cat external.cfg
[Common]
pki_admin_password=
pki_backup_password=
pki_client_pkcs12_password=
pki_ds_password=
pki_security_domain_password=
[Tomcat]
pki_ajp_port=18009
pki_http_port=18080
pki_https_port=18443
pki_instance_name=pki-external-tomcat
pki_tomcat_server_port=18005
* Next, Step 1 for a CA which depended upon this External CA was
created using the following command and file('# mv typescript
typescript.step_1' once finished):
o script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv'
# cat ca_1.cfg
[Common]
pki_admin_password=
pki_backup_password=
pki_client_pkcs12_password=
pki_ds_password=
pki_security_domain_password=
[CA]
pki_external=True
pki_external_csr_path=/tmp/pki/ca_signing.csr
* Next, the CSR contained in the file '/tmp/pki/ca_signing.csr' was
utilzed to create a certificate using the "External CA" using the
following procedure:
o External CA:
EE: Enrollment/Renewal Tab
* Use 'Manual Certificate Manager Signing Certificate
Enrollment'
AGENT: Approve request by pressing 'submit'
EE: Retrieval Tab
* Use 'Check Request Status' to obtain the base 64
encoded certificate
* Store this blob into the file specified by the value
of 'pki_external_ca_cert_path'in ca_2.cfg
EE: Retrieval Tab
* Use 'Import CA Certificate Chain' and select the
radio button entitled 'Display certificates in the CA
certificate chain for
importing individually into a server' to obtain the
base 64 encoded certificate chain
* Store this blob into the file specified by the value
of 'pki_external_ca_cert_chain_path'in ca_2.cfg
* Finally, Step 2 for a CA which depended upon this External CA was
created using the following command and file('# mv typescript
typescript.step_2' once finished):
o script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv'
# cat ca_2.cfg
[Common]
pki_admin_password=
pki_backup_password=
pki_client_pkcs12_password=
pki_ds_password=
pki_security_domain_password=
[CA]
pki_external=True
pki_external_ca_cert_chain_path=/tmp/pki/ca_signing_chain.cert
pki_external_ca_cert_path=/tmp/pki/ca_signing.cert
pki_external_step_two=True
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20121204-Implemented-ability-to-utilize-an-external-CA.patch
Type: text/x-patch
Size: 19244 bytes
Desc: not available
URL:
From alee at redhat.com Wed Dec 5 18:32:30 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 05 Dec 2012 13:32:30 -0500
Subject: [Pki-devel] [PATCH] Implemented ability to use an external CA
In-Reply-To: <50BEEA50.9080108@redhat.com>
References: <50BEEA50.9080108@redhat.com>
Message-ID: <1354732351.29745.18.camel@aleeredhat.laptop>
Comments:
1. In pkiparser, you add:
if not len(config.pki_master_dict['pki_security_domain_name']):
config.pki_master_dict['pki_security_domain_name'] =\
"External CA Security Domain"
We no longer distinguish security domains like this. The default as
defined by interpolation is fine.
2. I think we can remove the comment:
# always set 'pki_skip_installation' true using a 'string'
in initialization.py
3. In pkijython.py, you do:
elif config.str2bool(self.master['pki_external']) and\
config.str2bool(self.master['pki_external_step_two']):
# always remove pki_external DS data from external CA step 1
data.setRemoveData("true")
This means that we'll set up the database and then blow it away and set
it up again in step 2. Even more troubling, the request for the CA cert
is probably stored in the database during step 1 and is blown away in
step 2.
The better way to do this would be to modify the configuration servlet
to skip database population if we are doing external CA step 2.
4. In pkijython.py, you extract the pin from CS.cfg and overwrite the
existing pin. But perhaps a better thing to do would be to move this
code to pkiparser where the original pin is generated.
Ade
On Tue, 2012-12-04 at 22:31 -0800, Matthew Harmsen wrote:
> The attached patch addresses the following PKI issues:
> * TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle
> external CA
> This code has been successfully tested on a slightly earlier version
> of the source tree, although the attached patch has been re-based to
> the 'master'.
>
> To test this code, the following procedure was followed on an x86_64
> machine running 64-bit Fedora 18:
> * First, a standard CA was created to be used as an "External
> CA" using the following command and file ('# mv typescript
> typescript.external' once finished):
> * script -c 'pkispawn -s CA -f /tmp/pki/external.cfg
> -vvv'
>
> # cat external.cfg
> [Common]
> pki_admin_password=
> pki_backup_password=
> pki_client_pkcs12_password=
> pki_ds_password=
> pki_security_domain_password=
> [Tomcat]
> pki_ajp_port=18009
> pki_http_port=18080
> pki_https_port=18443
> pki_instance_name=pki-external-tomcat
> pki_tomcat_server_port=18005
>
> * Next, Step 1 for a CA which depended upon this External CA was
> created using the following command and file ('# mv typescript
> typescript.step_1' once finished):
> * script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv'
>
> # cat ca_1.cfg
> [Common]
> pki_admin_password=
> pki_backup_password=
> pki_client_pkcs12_password=
> pki_ds_password=
> pki_security_domain_password=
> [CA]
> pki_external=True
> pki_external_csr_path=/tmp/pki/ca_signing.csr
>
> * Next, the CSR contained in the file '/tmp/pki/ca_signing.csr'
> was utilzed to create a certificate using the "External CA"
> using the following procedure:
> * External CA:
>
> EE: Enrollment/Renewal Tab
> * Use 'Manual Certificate Manager Signing
> Certificate Enrollment'
>
> AGENT: Approve request by pressing 'submit'
>
> EE: Retrieval Tab
> * Use 'Check Request Status' to obtain the
> base 64 encoded certificate
> * Store this blob into the file specified by
> the value of 'pki_external_ca_cert_path' in ca_2.cfg
>
> EE: Retrieval Tab
> * Use 'Import CA Certificate Chain' and select
> the radio button entitled 'Display certificates in the
> CA certificate chain for
> importing individually into a server' to
> obtain the base 64 encoded certificate chain
> * Store this blob into the file specified by
> the value of 'pki_external_ca_cert_chain_path' in
> ca_2.cfg
>
> * Finally, Step 2 for a CA which depended upon this External CA
> was created using the following command and file ('# mv
> typescript typescript.step_2' once finished):
> * script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv'
>
> # cat ca_2.cfg
> [Common]
> pki_admin_password=
> pki_backup_password=
> pki_client_pkcs12_password=
> pki_ds_password=
> pki_security_domain_password=
> [CA]
> pki_external=True
> pki_external_ca_cert_chain_path=/tmp/pki/ca_signing_chain.cert
> pki_external_ca_cert_path=/tmp/pki/ca_signing.cert
> pki_external_step_two=True
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From mharmsen at redhat.com Thu Dec 6 22:37:29 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Thu, 06 Dec 2012 14:37:29 -0800
Subject: [Pki-devel] [PATCH] Implemented ability to use an external CA
In-Reply-To: <1354732351.29745.18.camel@aleeredhat.laptop>
References: <50BEEA50.9080108@redhat.com>
<1354732351.29745.18.camel@aleeredhat.laptop>
Message-ID: <50C11E29.9040200@redhat.com>
A revised patch has been attached to this email which addresses all of
the issues below.
All tests documented below have been run successfully against this patch.
NOTE: The tests have been modified slightly to comply with the latest
PKI source code.
On 12/05/12 10:32, Ade Lee wrote:
> Comments:
> 1. In pkiparser, you add:
> if not len(config.pki_master_dict['pki_security_domain_name']):
> config.pki_master_dict['pki_security_domain_name'] =\
> "External CA Security Domain"
>
> We no longer distinguish security domains like this. The default as
> defined by interpolation is fine.
>
> 2. I think we can remove the comment:
> # always set 'pki_skip_installation' true using a 'string'
> in initialization.py
>
> 3. In pkijython.py, you do:
> elif config.str2bool(self.master['pki_external']) and\
> config.str2bool(self.master['pki_external_step_two']):
> # always remove pki_external DS data from external CA step 1
> data.setRemoveData("true")
>
> This means that we'll set up the database and then blow it away and set
> it up again in step 2. Even more troubling, the request for the CA cert
> is probably stored in the database during step 1 and is blown away in
> step 2.
>
> The better way to do this would be to modify the configuration servlet
> to skip database population if we are doing external CA step 2.
>
> 4. In pkijython.py, you extract the pin from CS.cfg and overwrite the
> existing pin. But perhaps a better thing to do would be to move this
> code to pkiparser where the original pin is generated.
>
> Ade
>
> On Tue, 2012-12-04 at 22:31 -0800, Matthew Harmsen wrote:
>> The attached patch addresses the following PKI issues:
>> * TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle
>> external CA
>> This code has been successfully tested on a slightly earlier version
>> of the source tree, although the attached patch has been re-based to
>> the 'master'.
>>
>> To test this code, the following procedure was followed on an x86_64
>> machine running 64-bit Fedora 18:
>> * First, a standard CA was created to be used as an "External
>> CA" using the following command and file ('# mv typescript
>> typescript.external' once finished):
>> * script -c 'pkispawn -s CA -f /tmp/pki/external.cfg
>> -vvv'
>>
>> # cat external.cfg
>> [Common]
>> pki_admin_password=
>> pki_backup_password=
>> pki_client_pkcs12_password=
>> pki_ds_password=
>> pki_security_domain_password=
pki_http_port=18080
pki_https_port=18443
pki_instance_name=pki-external-tomcat
>> [Tomcat]
>> pki_ajp_port=18009
>> pki_tomcat_server_port=18005
>>
>> * Next, Step 1 for a CA which depended upon this External CA was
>> created using the following command and file ('# mv typescript
>> typescript.step_1' once finished):
>> * script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv'
>>
>> # cat ca_1.cfg
>> [Common]
>> pki_admin_password=
>> pki_backup_password=
>> pki_client_pkcs12_password=
>> pki_ds_password=
>> pki_security_domain_password=
>> [CA]
>> pki_external=True
>> pki_external_csr_path=/tmp/pki/config/ca_signing.csr
pki_ca_signing_subject_dn=CA Signing
Certificate,o=%{pki_security_domain_name)s External
>>
>> * Next, the CSR contained in the file '/tmp/pki/ca_signing.csr'
>> was utilzed to create a certificate using the "External CA"
>> using the following procedure:
>> * External CA:
>>
>> EE: Enrollment/Renewal Tab
>> * Use 'Manual Certificate Manager Signing
>> Certificate Enrollment'
>>
>> AGENT: Approve request by pressing 'submit'
>>
>> EE: Retrieval Tab
>> * Use 'Check Request Status' to obtain the
>> base 64 encoded certificate
>> * Store this blob into the file specified by
>> the value of 'pki_external_ca_cert_path' in ca_2.cfg
>>
>> EE: Retrieval Tab
>> * Use 'Import CA Certificate Chain' and select
>> the radio button entitled 'Display certificates in the
>> CA certificate chain for
>> importing individually into a server' to
>> obtain the base 64 encoded certificate chain
>> * Store this blob into the file specified by
>> the value of 'pki_external_ca_cert_chain_path' in
>> ca_2.cfg
>>
>> * Finally, Step 2 for a CA which depended upon this External CA
>> was created using the following command and file ('# mv
>> typescript typescript.step_2' once finished):
>> * script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv'
>>
>> # cat ca_2.cfg
>> [Common]
>> pki_admin_password=
>> pki_backup_password=
>> pki_client_pkcs12_password=
>> pki_ds_password=
>> pki_security_domain_password=
>> [CA]
>> pki_external=True
>> pki_external_ca_cert_chain_path=/tmp/pki/config/ca_signing_chain.cert
>> pki_external_ca_cert_path=/tmp/pki/config/ca_signing.cert
>> pki_external_step_two=True
pki_ca_signing_subject_dn=CA Signing
Certificate,o=%{pki_security_domain_name)s External
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
* Additionally, as a final sanity test, a default KRA was created
re-utilizing the 'ca_1.cfg' file ('# mv typescript typescript.kra'
once finished):
o script -c 'pkispawn -s KRA -f /tmp/pki/ca_1.cfg -vvv'
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20121206-Implemented-ability-to-utilize-an-external-CA.patch
Type: text/x-patch
Size: 21847 bytes
Desc: not available
URL:
From edewata at redhat.com Fri Dec 7 00:57:31 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 06 Dec 2012 18:57:31 -0600
Subject: [Pki-devel] [PATCH] 198 Parameterizing RESTEasy paths.
Message-ID: <50C13EFB.7060801@redhat.com>
The paths to RESTEasy jar files have been modified such that it can
be configured globally at build time using the spec file to support
different distributions, and at deployment time using a system-wide
configuration in /etc/pki/pki.conf.
Ticket #422, #423.
--
Endi S. Dewata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-edewata-0198-Parameterizing-RESTEasy-paths.patch
Type: text/x-patch
Size: 31013 bytes
Desc: not available
URL:
From edewata at redhat.com Fri Dec 7 02:24:53 2012
From: edewata at redhat.com (Endi Sukma Dewata)
Date: Thu, 06 Dec 2012 20:24:53 -0600
Subject: [Pki-devel] [PATCH] 198 Parameterizing RESTEasy paths.
In-Reply-To: <50C13EFB.7060801@redhat.com>
References: <50C13EFB.7060801@redhat.com>
Message-ID: <50C15375.1090606@redhat.com>
On 12/6/2012 6:57 PM, Endi Sukma Dewata wrote:
> The paths to RESTEasy jar files have been modified such that it can
> be configured globally at build time using the spec file to support
> different distributions, and at deployment time using a system-wide
> configuration in /etc/pki/pki.conf.
>
> Ticket #422, #423.
ACKed by Ade, pushed to master.
--
Endi S. Dewata
From alee at redhat.com Fri Dec 7 05:55:43 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 07 Dec 2012 00:55:43 -0500
Subject: [Pki-devel] [PATCH] 97 - Remove-server-code-from-CertSearchRequest
Message-ID: <1354859743.29745.36.camel@aleeredhat.laptop>
Pretty straightforward. Please review.
Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0097-Remove-server-code-from-CertSearchRequest.patch
Type: text/x-patch
Size: 26621 bytes
Desc: not available
URL:
From alee at redhat.com Fri Dec 7 06:02:43 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 07 Dec 2012 01:02:43 -0500
Subject: [Pki-devel] [PATCH] 97 -
Remove-server-code-from-CertSearchRequest
In-Reply-To: <1354859743.29745.36.camel@aleeredhat.laptop>
References: <1354859743.29745.36.camel@aleeredhat.laptop>
Message-ID: <1354860164.29745.37.camel@aleeredhat.laptop>
Acked by Matt. Pushed to master.
On Fri, 2012-12-07 at 00:55 -0500, Ade Lee wrote:
> Pretty straightforward. Please review.
>
> Ade
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From akoneru at redhat.com Fri Dec 7 14:59:56 2012
From: akoneru at redhat.com (Abhishek Koneru)
Date: Fri, 07 Dec 2012 09:59:56 -0500
Subject: [Pki-devel] [PATCH] 35 Fix for ticket 214 - Proper error message
while adding duplicate user
Message-ID: <1354892396.32653.3.camel@akoneru.redhat.com>
Please review the patch which fixes the ticket 214. It requires Patch 34
which is also attached to be applied first.
--Abhishek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-akoneru-0034-Ticket-191-Mapping-HTTP-Exception-to-their-proper-HT.patch
Type: text/x-patch
Size: 72524 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-akoneru-0035-Ticket-214-Proper-error-message-when-adding-a-duplic.patch
Type: text/x-patch
Size: 4233 bytes
Desc: not available
URL:
From alee at redhat.com Fri Dec 7 20:38:51 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 07 Dec 2012 15:38:51 -0500
Subject: [Pki-devel] [PATCH] 98 - man page edits
Message-ID: <1354912731.29745.38.camel@aleeredhat.laptop>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0098-Added-more-detail-to-man-page-for-pki-1.patch
Type: text/x-patch
Size: 8591 bytes
Desc: not available
URL:
From alee at redhat.com Fri Dec 7 20:54:08 2012
From: alee at redhat.com (Ade Lee)
Date: Fri, 07 Dec 2012 15:54:08 -0500
Subject: [Pki-devel] [PATCH] 98 - man page edits
In-Reply-To: <1354912731.29745.38.camel@aleeredhat.laptop>
References: <1354912731.29745.38.camel@aleeredhat.laptop>
Message-ID: <1354913649.29745.39.camel@aleeredhat.laptop>
more edits.
On Fri, 2012-12-07 at 15:38 -0500, Ade Lee wrote:
> _______________________________________________
> 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-0098-1-Added-more-detail-to-man-page-for-pki-1.patch
Type: text/x-patch
Size: 8545 bytes
Desc: not available
URL:
From alee at redhat.com Mon Dec 10 18:42:23 2012
From: alee at redhat.com (Ade Lee)
Date: Mon, 10 Dec 2012 13:42:23 -0500
Subject: [Pki-devel] [PATCH] 99 - man page updates
Message-ID: <1355164943.10814.0.camel@aleeredhat.laptop>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0099-More-edits-to-man-pages.patch
Type: text/x-patch
Size: 19553 bytes
Desc: not available
URL:
From awnuk at redhat.com Tue Dec 11 00:47:37 2012
From: awnuk at redhat.com (Andrew Wnuk)
Date: Mon, 10 Dec 2012 16:47:37 -0800
Subject: [Pki-devel] [PATCH] authentication plugin
Message-ID: <50C682A9.30504@redhat.com>
This patch provides authentication plugin avoiding anonymous access.
Bug 861467.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: authentication-plugin.patch
Type: text/x-patch
Size: 18160 bytes
Desc: not available
URL:
From mharmsen at redhat.com Tue Dec 11 00:53:33 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Mon, 10 Dec 2012 16:53:33 -0800
Subject: [Pki-devel] [PATCH] authentication plugin
In-Reply-To: <50C682A9.30504@redhat.com>
References: <50C682A9.30504@redhat.com>
Message-ID: <50C6840D.4010306@redhat.com>
On 12/10/12 16:47, Andrew Wnuk wrote:
> This patch provides authentication plugin avoiding anonymous access.
>
> Bug 861467.
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
ACK
Received demo of this patch for Dogtag 9.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From alee at redhat.com Tue Dec 11 19:11:24 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 11 Dec 2012 14:11:24 -0500
Subject: [Pki-devel] Announcing Dogtag 10.0 Release Candidate 1
Message-ID: <1355253084.2513.59.camel@aleeredhat.laptop>
The Dogtag team is proud to announce version Dogtag v10.0.0 Release
Candidate 1.
A build is available for Fedora 18 in the updates-testing repo. Please
try it out and provide karma to move it to the F18 stable repo.
Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/
== Build Versions ==
pki-core-10.0.0-2.fc18
pki-ra-10.0.0-1.fc18
pki-tps-10.0.0-1.fc18
dogtag-pki-10.0.0-1.fc18
dogtag-pki-theme-10.0.0-1.fc18
pki-console-10.0.0-1.fc18
== Highlights since Dogtag v. 10.0.0 beta 2 (Oct 30 2012) ==
* Simplified and enhanced pkispawn.
** Added detailed man pages to document use of pkispawn, pkidestroy
and the command line utility pki.
** Removed --dry-run option and unused respawn() code.
** Replaced links of scriptlets with lists
** Modified the way pkispawn parses configuration files. pkispawn now
reads a template file for default settings, and a much smaller and
simpler user-defined configuration file for customizations and
overrides. Moreover, pkispawn uses interpolation to substitute in
values. See the man pages for details.
** Added the ability to import an admin cert into the administrative
user created for each subsystem. This allows multiple subsystems
within the same instance to be more easily managed within the same
browser.
** Implemented ability to install a subordinate CA using pkispawn.
** Implemented ability to install an externally signed CA using
pkispawn.
* Simplified the structure of the UI packages
** All images and css files have been moved to dogtag-pki-server-theme
for all subsystems.
** Removed unused and duplicated files.
** Template files have been moved to the underlying subsystem files.
In future, all theme related messages in those files will be
parameterized and placed in dogtag-pki-server-theme. This will
significantly simplify the process of customizing or
internationalizing an instance and its theme.
** Retired all the subsystem specific UI packages, reducing the number
of UI packages from 7 to 1.
* Security fixes for CVE-2012-4543 Certificate System: Multiple
cross-site scripting flaws by displaying CRL or processing.
* Memory fixes for the TPS
* Updated to latest version of cmake, removing obsolete modules.
== Notes for F17 ==
* Only developer builds are available for F17.
* F17 tomcat used to have a bug in the way it handles pid files.
https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you
have at least tomcat-7.0.32-1.fc17.
== Feedback ==
Please provide comments, bugs and other feedback via the pki-devel
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel
== Detailed Changelog ==
akoneru (2):
0667896 Fix for improper crl retrieval from CA.
f400f3b Invalid ACL resources Fix in KRA for certServer.kra.keys
alee (25):
6e77f33 Updated pki-core spec file to 10.0.0-2
a505c8c fix typo in spec file
f73a662 Update to rc1 build
1e46576 Added more detail to man page for pki(1)
cbfdae8 Remove server code from CertSearchRequest
cd279e3 Modified section on sample.cfg
a3f7d58 Interpolation correction patch based on review comments
065d883 Use interpolation to build default parameters
35dc100 Change the structure of the client directory.
03a6350 Common User: pkispawn changes
6be1194 Common admin user: config servlet changes
871b442 Misc changes to get rhel 7 build to work
40e58f9 Link to resteasy-base on rhel systems when running pkispawn
96af71d Removed obsolete cmake modules, updated spec files
9862a04 Updating cmake variables
440a9e7 removed obsolete cmake modules
1de7c91 Change cmake projects from Java to NONE
2efc66e spec file changes
999a0f1 Added missing Provides
eb74b11 update to b3
64eaca2 Fix issue with pki_external being referenced for non-CA
318716f removed dry_run from pkispawn
019a933 Remove unused respawn code.
a80e994 Convert admin cert from a to b before importing to certdb
db9537d Set paths for default instance
awnuk(1):
883e0ec number verification
edewata (52):
9996d71 Parameterizing RESTEasy paths.
81bb209 Archiving default deployment configuration.
66c519f I18n for ProfileList.template.
a4c95c3 Removed RA and TPS theme packages.
3dfee91 Reorganized TPS CSS files.
d8f56d8 Reorganized TPS templates and scripts.
538dee3 Reorganized RA templates and scripts.
083e130 Fixed permission problem in TKS.
6344d6e Replaced links of scriptlets with lists.
471a493 Simplified the configuration file using defaults.
5e93dc2 Reorganized sensitive parameters.
cef7a77 Fixed issuedOn parameters for cert-find.
ba1e743 Fixed default security domain user.
68751fb Refactored pkiparser.py into PKIConfigParser.
9bb7143 Removed CA, KRA, OCSP, TKS theme packages.
46fda5d Reorganized CA, KRA, OCSP, TKS templates.
edf9c22 Reorganized common templates.
c8336ea Renamed pki-common-theme to pki-server-theme.
105ffbd Reorganized ESC images.
545b796 Removed unused files in tps-ui.
f3e20fc Removed unused files in ra-ui.
6197b95 Removed unused files in tks-ui.
b45fc00 Removed unused files in ocsp-ui.
d248593 Removed unused files in kra-ui.
42f48ab Removed unused files in ca-ui.
41e061f Removed unused files in common-ui.
fb80a25 Updated tools to deploy combined images and CSS files.
4109bc3 Combined theme images and CSS files into common-ui.
515e882 Fixed pkisilent build problem.
cb209df Added ACLInterceptor.
87556b7 Update pki-base.css paths.
386d703 Updated rootca.gif and sub.gif paths.
6a1302a Updated icon-software.gif paths.
1ca3b21 Updated icon_crit_update.gif paths.
d7306c4 Updated clearpixel.gif paths.
599a3e7 Updated certificate.png and no-certificate.png paths.
5a14647 Updated bigrotation2.gif paths.
d5802a7 Updated lgRightTab2.gif paths.
33746d8 Updated dgRightTab2.gif paths.
918764d Updated lgRightTab.gif paths.
6e836a6 Updated lgLeftTab.gif paths.
792becd Updated goto-tall.gif paths.
3b4a7e4 Updated dgRightTab.gif paths.
122b650 Updated dgLeftTab.gif paths.
45aff6c Updated spacer.gif paths.
137d8f9 Updated hr.gif paths.
810ecfe Updated gray90.gif paths.
f077cf4 Updated logo_header.gif paths.
a959d7d Updated favicon.ico paths.
70a0dd8 Merged theme files.
d9a9e23 Fixed problem finding SHA-256 message digest.
8eb2ccf Fixed PrettyPrintCert and PrettyPrintCrl.
jmagne(1):
6180bb1 Latest TPS memory related fixes.
mharmsen (9):
70938da More edits to man pages including spell checking via 'aspell'.
34851bb Revised 'pki_default.cfg5' man page.
e7b7d98 Added man pages.
8d5eb93 Implemented ability to utilize an external CA
6a1cf64 Removed 'pki/base/silent/templates/subca_silent.template'.
af58413 Move default location for client cert database (pkisilent)
cfcd015 Move default location for client certificate database
1e15712 Enable Subordinate CA
906acfd Enable building on ARM architecture.
From cfu at redhat.com Wed Dec 12 00:51:21 2012
From: cfu at redhat.com (Christina Fu)
Date: Tue, 11 Dec 2012 16:51:21 -0800
Subject: [Pki-devel] Review Request: CMC ECC support
Message-ID: <50C7D509.7090007@redhat.com>
The following code is ready for review for task
https://fedorahosted.org/pki/ticket/362
Feature: CMC ECC
which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well as
CMC Response checking support needed HTTPClient ECC support.
It should inherently fix the following existing bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC CRMF
https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC
revoke
attachment:
https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff
Code changes involve both server and several tools.
I will do some writeup and provide example on how to test in the task
comment later.
thanks!
Christina
From alee at redhat.com Tue Dec 18 18:23:17 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 18 Dec 2012 13:23:17 -0500
Subject: [Pki-devel] [PATCH] 101-107 Various fixes for pkispawn etc.
Message-ID: <1355854998.15924.11.camel@aleeredhat.laptop>
Please review.
Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0107-Revert-to-using-default-config-file-for-pkidestroy.patch
Type: text/x-patch
Size: 3573 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0106-Hardcode-setting-of-resteasy-lib-for-instance.patch
Type: text/x-patch
Size: 3143 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0105-interpolate-more-paths.patch
Type: text/x-patch
Size: 27609 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0104-interpolated-jars.patch
Type: text/x-patch
Size: 28539 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0102-Removed-duplicate-pki_instance_id-parameter.patch
Type: text/x-patch
Size: 34172 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0101-Replace-file-dependencies-with-package-dependencies.patch
Type: text/x-patch
Size: 1730 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0103-interpolation-for-paths-part-1.patch
Type: text/x-patch
Size: 16840 bytes
Desc: not available
URL:
From alee at redhat.com Tue Dec 18 21:38:46 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 18 Dec 2012 16:38:46 -0500
Subject: [Pki-devel] [PATCH] More fixes to pkispawn - 108, 109
Message-ID: <1355866726.15924.13.camel@aleeredhat.laptop>
Please review.
Ade
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0109-Make-admin-cert-p12-file-location-configurable.patch
Type: text/x-patch
Size: 6980 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0108-pkispawn-modified-to-not-relabel-when-selinux-is-dis.patch
Type: text/x-patch
Size: 4419 bytes
Desc: not available
URL:
From mharmsen at redhat.com Tue Dec 18 22:53:44 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 18 Dec 2012 14:53:44 -0800
Subject: [Pki-devel] [PATCH] 101-107 Various fixes for pkispawn etc.
In-Reply-To: <1355854998.15924.11.camel@aleeredhat.laptop>
References: <1355854998.15924.11.camel@aleeredhat.laptop>
Message-ID: <50D0F3F8.5040908@redhat.com>
On 12/18/12 10:23, Ade Lee wrote:
> Please review.
>
> Ade
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
*ACK*
Performed the following tests on x86_64 Fedora 18:
* Existing CA (from legacy 'pkispawn CA')
* Update 'pki-core' packages - *SUCCESS*
* stop/start CA - *SUCCESS*
* enroll using 'Manual User Dual-Use Certificate Enrollment
'
- *SUCCESS*
* pkispawn KRA - *SUCCESS*
o filed *TRAC Ticket #463 - **Dogtag 10: Choose either 'DRM' or
'KRA' for nicknames (not both)*
* enroll using 'Manual User Signing & Encryption Certificates
Enrollment
'
- *SUCCESS*
* pkidestroy KRA - *SUCCESS*
* enroll using 'Manual User Dual-Use Certificate Enrollment
'
- *SUCCESS*
* enroll using 'Manual User Signing & Encryption Certificates
Enrollment
'
o
The Certificate System has encountered an unrecoverable error.
Error Message:
/java.lang.NullPointerException/
Please contact your local administrator for assistance.
o related to*TRAC Ticket #367 -pkidestroy doesn't remove connector*
* pkidestroy CA - *SUCCESS*
* pkispawn CA - *SUCCESS*
* enroll using 'Manual User Dual-Use Certificate Enrollment
'
- *SUCCESS*
* pkispawn KRA - *SUCCESS*
* enroll using 'Manual User Signing & Encryption Certificates
Enrollment
'
- *SUCCESS*
* pkidestroy KRA - *SUCCESS*
* enroll using 'Manual User Dual-Use Certificate Enrollment
'
- *SUCCESS*
* pkidestroy CA - *SUCCESS*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From alee at redhat.com Wed Dec 19 02:43:57 2012
From: alee at redhat.com (Ade Lee)
Date: Tue, 18 Dec 2012 21:43:57 -0500
Subject: [Pki-devel] [PATCH] 101-107 Various fixes for pkispawn etc.
In-Reply-To: <50D0F3F8.5040908@redhat.com>
References: <1355854998.15924.11.camel@aleeredhat.laptop>
<50D0F3F8.5040908@redhat.com>
Message-ID: <1355885038.15924.15.camel@aleeredhat.laptop>
Thanks. Pushed to master.
Also pushed a patch with punctuation and formatting changes to the man
pages from Deon.
Ade
On Tue, 2012-12-18 at 14:53 -0800, Matthew Harmsen wrote:
> On 12/18/12 10:23, Ade Lee wrote:
>
> > Please review.
> >
> > Ade
> >
> >
> >
> > _______________________________________________
> > Pki-devel mailing list
> > Pki-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> ACK
>
> Performed the following tests on x86_64 Fedora 18:
> * Existing CA (from legacy 'pkispawn CA')
> * Update 'pki-core' packages - SUCCESS
> * stop/start CA - SUCCESS
> * enroll using 'Manual User Dual-Use Certificate Enrollment' -
> SUCCESS
> * pkispawn KRA - SUCCESS
> * filed TRAC Ticket #463 - Dogtag 10: Choose either
> 'DRM' or 'KRA' for nicknames (not both)
> * enroll using 'Manual User Signing & Encryption Certificates
> Enrollment' - SUCCESS
> * pkidestroy KRA - SUCCESS
> * enroll using 'Manual User Dual-Use Certificate Enrollment' -
> SUCCESS
> * enroll using 'Manual User Signing & Encryption Certificates
> Enrollment'
> * The Certificate System has encountered an
> unrecoverable error.
>
> Error Message:
> java.lang.NullPointerException
>
> Please contact your local administrator for
> assistance.
>
> * related to TRAC Ticket #367 -pkidestroy doesn't remove
> connector
> * pkidestroy CA - SUCCESS
> * pkispawn CA - SUCCESS
> * enroll using 'Manual User Dual-Use Certificate Enrollment' -
> SUCCESS
> * pkispawn KRA - SUCCESS
> * enroll using 'Manual User Signing & Encryption Certificates
> Enrollment' - SUCCESS
> * pkidestroy KRA - SUCCESS
> * enroll using 'Manual User Dual-Use Certificate Enrollment' -
> SUCCESS
> * pkidestroy CA - SUCCESS
>
From mharmsen at redhat.com Wed Dec 19 03:36:40 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Tue, 18 Dec 2012 19:36:40 -0800
Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . .
Message-ID: <50D13648.5070400@redhat.com>
The attached patch addresses the following PKI issue:
* TRAC Ticket #271 - Dogtag 10: Fix 'status' command in 'pkidaemon' . . .
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20121218-TRAC-Ticket-271-Dogtag-10-Fix-status-command-in-pkid.patch
Type: text/x-patch
Size: 14693 bytes
Desc: not available
URL:
From cfu at redhat.com Wed Dec 19 04:44:27 2012
From: cfu at redhat.com (Christina Fu)
Date: Tue, 18 Dec 2012 20:44:27 -0800
Subject: [Pki-devel] Review Request: CMC ECC support
In-Reply-To: <50C7D509.7090007@redhat.com>
References: <50C7D509.7090007@redhat.com>
Message-ID: <50D1462B.9090206@redhat.com>
Please find a newer patch which now also includes support for CMC
revocation within the CMCRequest tool and op flags for EC key generation
in CRMFPopClient and PKCS10Client.
https://fedorahosted.org/pki/ticket/362
You will also find various Examples on how to test different scenarios
in regards to CMC request issuance.
thanks,
Christina
On 12/11/2012 04:51 PM, Christina Fu wrote:
> The following code is ready for review for task
> https://fedorahosted.org/pki/ticket/362
> Feature: CMC ECC
> which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well
> as CMC Response checking support needed HTTPClient ECC support.
> It should inherently fix the following existing bugs:
> https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC
> CRMF
> https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC
> revoke
>
> attachment:
> https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff
>
> Code changes involve both server and several tools.
>
> I will do some writeup and provide example on how to test in the task
> comment later.
>
> thanks!
> Christina
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Wed Dec 19 05:09:21 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 19 Dec 2012 00:09:21 -0500
Subject: [Pki-devel] [PATCH] More fixes to pkispawn - 108, 109
In-Reply-To: <1355866726.15924.13.camel@aleeredhat.laptop>
References: <1355866726.15924.13.camel@aleeredhat.laptop>
Message-ID: <1355893762.15924.16.camel@aleeredhat.laptop>
Acked by Matt. Pushed to master.
On Tue, 2012-12-18 at 16:38 -0500, Ade Lee wrote:
> Please review.
>
> Ade
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Wed Dec 19 17:29:05 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 19 Dec 2012 12:29:05 -0500
Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . .
In-Reply-To: <50D13648.5070400@redhat.com>
References: <50D13648.5070400@redhat.com>
Message-ID: <1355938146.15924.33.camel@aleeredhat.laptop>
I found the following issues:
Issue 1:
Lets say I have the following setup:
instance A with subsystems CA, KRA, OCSP
instance B with subsystem CA, KRA
Then for instance B, I see the following error message:
grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or directory
pki-tomcat27 Configuration Definitions not found for ocsp
It appears that if any instance has a subsystem, then it is assumed that
all instances have that subsystem because you use a global list of
subsystems.
Issue 2:
This may be a pkidestroy problem. I did a pkidestroy of the OCSP on
instance A. Now I see the following:
[CA Status Definitions]
Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca
Secure Agent Port = https://alee-workpc.redhat.com:8223/ca/agent/ca
Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca
Secure Admin Port = https://alee-workpc.redhat.com:8223/ca/services
EE Client Auth Port = https://alee-workpc.redhat.com:8223/ca/eeca/ca
PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ca
Tomcat Port = 8225 (for shutdown)
[DRM Status Definitions]
Unsecure Port = http://alee-workpc.redhat.com:8220/kra/ee/kra
Secure Agent Port = https://alee-workpc.redhat.com:8223/kra/agent/kra
Secure EE Port = https://alee-workpc.redhat.com:8223/kra/ee/kra
Secure Admin Port = https://alee-workpc.redhat.com:8223/kra/services
PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/kra
Tomcat Port = 8225 (for shutdown)
Unsecure Port = http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp
Secure Agent Port = https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp
Secure EE Port = https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp
Secure Admin Port = https://alee-workpc.redhat.com:8223/ocsp/services
PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ocsp
Tomcat Port = 8225 (for shutdown)
That is -- I still see definitions from the removed OCSP. Ditto if I
remove the KRA.
Maybe this is a weird instance. Still testing ..
On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote:
> The attached patch addresses the following PKI issue:
> * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in
> 'pkidaemon' . . .
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
From alee at redhat.com Wed Dec 19 17:46:34 2012
From: alee at redhat.com (Ade Lee)
Date: Wed, 19 Dec 2012 12:46:34 -0500
Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . .
In-Reply-To: <1355938146.15924.33.camel@aleeredhat.laptop>
References: <50D13648.5070400@redhat.com>
<1355938146.15924.33.camel@aleeredhat.laptop>
Message-ID: <1355939195.15924.38.camel@aleeredhat.laptop>
OK -- I tried this --
1. Install instance A with CA, KRA
2. Install instance B with CA. At this point, status shows me error on
not being able to find KRA files on instance B.
3. Install OCSP on instance A.
4. Remove OCSP on instance A. Other than problem mentioned above, all
looks ok.
5. Install OCSP on instance B.
I see this for B:
Status for pki-tomcat28: pki-tomcat28 is running ..
[CA Status Definitions]
Unsecure Port = http://alee-workpc.redhat.com:8280/ca/ee/ca
Secure Agent Port = https://alee-workpc.redhat.com:8283/ca/agent/ca
Secure EE Port = https://alee-workpc.redhat.com:8283/ca/ee/ca
Secure Admin Port = https://alee-workpc.redhat.com:8283/ca/services
EE Client Auth Port = https://alee-workpc.redhat.com:8283/ca/eeca/ca
PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ca
Tomcat Port = 8285 (for shutdown)
Unsecure Port = http://alee-workpc.redhat.com:8280/kra/ee/kra
Secure Agent Port = https://alee-workpc.redhat.com:8283/kra/agent/kra
Secure EE Port = https://alee-workpc.redhat.com:8283/kra/ee/kra
Secure Admin Port = https://alee-workpc.redhat.com:8283/kra/services
PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/kra
Tomcat Port = 8285 (for shutdown)
[OCSP Status Definitions]
Unsecure Port = http://alee-workpc.redhat.com:8280/ocsp/ee/ocsp
Secure Agent Port = https://alee-workpc.redhat.com:8283/ocsp/agent/ocsp
Secure EE Port = https://alee-workpc.redhat.com:8283/ocsp/ee/ocsp
Secure Admin Port = https://alee-workpc.redhat.com:8283/ocsp/services
PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ocsp
Tomcat Port = 8285 (for shutdown)
Looks like you are not parsing the server.conf correctly.
On Wed, 2012-12-19 at 12:29 -0500, Ade Lee wrote:
> I found the following issues:
>
> Issue 1:
>
> Lets say I have the following setup:
> instance A with subsystems CA, KRA, OCSP
> instance B with subsystem CA, KRA
>
> Then for instance B, I see the following error message:
>
> grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or directory
> pki-tomcat27 Configuration Definitions not found for ocsp
>
> It appears that if any instance has a subsystem, then it is assumed that
> all instances have that subsystem because you use a global list of
> subsystems.
>
> Issue 2:
>
> This may be a pkidestroy problem. I did a pkidestroy of the OCSP on
> instance A. Now I see the following:
>
> [CA Status Definitions]
> Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca
> Secure Agent Port = https://alee-workpc.redhat.com:8223/ca/agent/ca
> Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca
> Secure Admin Port = https://alee-workpc.redhat.com:8223/ca/services
> EE Client Auth Port = https://alee-workpc.redhat.com:8223/ca/eeca/ca
> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ca
> Tomcat Port = 8225 (for shutdown)
>
> [DRM Status Definitions]
> Unsecure Port = http://alee-workpc.redhat.com:8220/kra/ee/kra
> Secure Agent Port = https://alee-workpc.redhat.com:8223/kra/agent/kra
> Secure EE Port = https://alee-workpc.redhat.com:8223/kra/ee/kra
> Secure Admin Port = https://alee-workpc.redhat.com:8223/kra/services
> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/kra
> Tomcat Port = 8225 (for shutdown)
> Unsecure Port = http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp
> Secure Agent Port = https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp
> Secure EE Port = https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp
> Secure Admin Port = https://alee-workpc.redhat.com:8223/ocsp/services
> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ocsp
> Tomcat Port = 8225 (for shutdown)
>
> That is -- I still see definitions from the removed OCSP. Ditto if I
> remove the KRA.
>
> Maybe this is a weird instance. Still testing ..
>
>
>
> On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote:
> > The attached patch addresses the following PKI issue:
> > * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in
> > 'pkidaemon' . . .
> >
> > _______________________________________________
> > 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 Wed Dec 19 19:35:18 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 19 Dec 2012 11:35:18 -0800
Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . .
In-Reply-To: <1355939195.15924.38.camel@aleeredhat.laptop>
References: <50D13648.5070400@redhat.com>
<1355938146.15924.33.camel@aleeredhat.laptop>
<1355939195.15924.38.camel@aleeredhat.laptop>
Message-ID: <50D216F6.30302@redhat.com>
Ade,
The attached patch should address these issues.
-- Matt
On 12/19/12 09:46, Ade Lee wrote:
> OK -- I tried this --
>
> 1. Install instance A with CA, KRA
> 2. Install instance B with CA. At this point, status shows me error on
> not being able to find KRA files on instance B.
> 3. Install OCSP on instance A.
> 4. Remove OCSP on instance A. Other than problem mentioned above, all
> looks ok.
> 5. Install OCSP on instance B.
>
> I see this for B:
> Status for pki-tomcat28: pki-tomcat28 is running ..
>
> [CA Status Definitions]
> Unsecure Port = http://alee-workpc.redhat.com:8280/ca/ee/ca
> Secure Agent Port = https://alee-workpc.redhat.com:8283/ca/agent/ca
> Secure EE Port = https://alee-workpc.redhat.com:8283/ca/ee/ca
> Secure Admin Port = https://alee-workpc.redhat.com:8283/ca/services
> EE Client Auth Port = https://alee-workpc.redhat.com:8283/ca/eeca/ca
> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ca
> Tomcat Port = 8285 (for shutdown)
> Unsecure Port = http://alee-workpc.redhat.com:8280/kra/ee/kra
> Secure Agent Port = https://alee-workpc.redhat.com:8283/kra/agent/kra
> Secure EE Port = https://alee-workpc.redhat.com:8283/kra/ee/kra
> Secure Admin Port = https://alee-workpc.redhat.com:8283/kra/services
> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/kra
> Tomcat Port = 8285 (for shutdown)
>
> [OCSP Status Definitions]
> Unsecure Port = http://alee-workpc.redhat.com:8280/ocsp/ee/ocsp
> Secure Agent Port = https://alee-workpc.redhat.com:8283/ocsp/agent/ocsp
> Secure EE Port = https://alee-workpc.redhat.com:8283/ocsp/ee/ocsp
> Secure Admin Port = https://alee-workpc.redhat.com:8283/ocsp/services
> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ocsp
> Tomcat Port = 8285 (for shutdown)
>
> Looks like you are not parsing the server.conf correctly.
>
>
> On Wed, 2012-12-19 at 12:29 -0500, Ade Lee wrote:
>> I found the following issues:
>>
>> Issue 1:
>>
>> Lets say I have the following setup:
>> instance A with subsystems CA, KRA, OCSP
>> instance B with subsystem CA, KRA
>>
>> Then for instance B, I see the following error message:
>>
>> grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or directory
>> pki-tomcat27 Configuration Definitions not found for ocsp
>>
>> It appears that if any instance has a subsystem, then it is assumed that
>> all instances have that subsystem because you use a global list of
>> subsystems.
>>
>> Issue 2:
>>
>> This may be a pkidestroy problem. I did a pkidestroy of the OCSP on
>> instance A. Now I see the following:
>>
>> [CA Status Definitions]
>> Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca
>> Secure Agent Port = https://alee-workpc.redhat.com:8223/ca/agent/ca
>> Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca
>> Secure Admin Port = https://alee-workpc.redhat.com:8223/ca/services
>> EE Client Auth Port = https://alee-workpc.redhat.com:8223/ca/eeca/ca
>> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ca
>> Tomcat Port = 8225 (for shutdown)
>>
>> [DRM Status Definitions]
>> Unsecure Port = http://alee-workpc.redhat.com:8220/kra/ee/kra
>> Secure Agent Port = https://alee-workpc.redhat.com:8223/kra/agent/kra
>> Secure EE Port = https://alee-workpc.redhat.com:8223/kra/ee/kra
>> Secure Admin Port = https://alee-workpc.redhat.com:8223/kra/services
>> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/kra
>> Tomcat Port = 8225 (for shutdown)
>> Unsecure Port = http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp
>> Secure Agent Port = https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp
>> Secure EE Port = https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp
>> Secure Admin Port = https://alee-workpc.redhat.com:8223/ocsp/services
>> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ocsp
>> Tomcat Port = 8225 (for shutdown)
>>
>> That is -- I still see definitions from the removed OCSP. Ditto if I
>> remove the KRA.
>>
>> Maybe this is a weird instance. Still testing ..
>>
>>
>>
>> On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote:
>>> The attached patch addresses the following PKI issue:
>>> * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in
>>> 'pkidaemon' . . .
>>>
>>> _______________________________________________
>>> 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: 20121219-TRAC-Ticket-271-Dogtag-10-Fix-status-command-in-pkid.patch
Type: text/x-patch
Size: 15314 bytes
Desc: not available
URL:
From mharmsen at redhat.com Wed Dec 19 19:53:33 2012
From: mharmsen at redhat.com (Matthew Harmsen)
Date: Wed, 19 Dec 2012 11:53:33 -0800
Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . .
In-Reply-To: <50D216F6.30302@redhat.com>
References: <50D13648.5070400@redhat.com>
<1355938146.15924.33.camel@aleeredhat.laptop>
<1355939195.15924.38.camel@aleeredhat.laptop>
<50D216F6.30302@redhat.com>
Message-ID: <50D21B3D.8090006@redhat.com>
ACKed by alee and checked-in (with the collapsed conditional discussed).
commit 01bbfc224a228206fbe18318b2a23363fa9663cc
Author: Matthew Harmsen
Date: Wed Dec 19 11:49:57 2012 -0800
TRAC Ticket #271 - Dogtag 10: Fix 'status' command in
'pkidaemon' . . .
On 12/19/12 11:35, Matthew Harmsen wrote:
> Ade,
>
> The attached patch should address these issues.
>
> -- Matt
>
> On 12/19/12 09:46, Ade Lee wrote:
>> OK -- I tried this --
>>
>> 1. Install instance A with CA, KRA
>> 2. Install instance B with CA. At this point, status shows me error on
>> not being able to find KRA files on instance B.
>> 3. Install OCSP on instance A.
>> 4. Remove OCSP on instance A. Other than problem mentioned above, all
>> looks ok.
>> 5. Install OCSP on instance B.
>>
>> I see this for B:
>> Status for pki-tomcat28: pki-tomcat28 is running ..
>>
>> [CA Status Definitions]
>> Unsecure Port = http://alee-workpc.redhat.com:8280/ca/ee/ca
>> Secure Agent Port =
>> https://alee-workpc.redhat.com:8283/ca/agent/ca
>> Secure EE Port = https://alee-workpc.redhat.com:8283/ca/ee/ca
>> Secure Admin Port =
>> https://alee-workpc.redhat.com:8283/ca/services
>> EE Client Auth Port =
>> https://alee-workpc.redhat.com:8283/ca/eeca/ca
>> PKI Console Port = pkiconsole
>> https://alee-workpc.redhat.com:8283/ca
>> Tomcat Port = 8285 (for shutdown)
>> Unsecure Port = http://alee-workpc.redhat.com:8280/kra/ee/kra
>> Secure Agent Port =
>> https://alee-workpc.redhat.com:8283/kra/agent/kra
>> Secure EE Port =
>> https://alee-workpc.redhat.com:8283/kra/ee/kra
>> Secure Admin Port =
>> https://alee-workpc.redhat.com:8283/kra/services
>> PKI Console Port = pkiconsole
>> https://alee-workpc.redhat.com:8283/kra
>> Tomcat Port = 8285 (for shutdown)
>>
>> [OCSP Status Definitions]
>> Unsecure Port =
>> http://alee-workpc.redhat.com:8280/ocsp/ee/ocsp
>> Secure Agent Port =
>> https://alee-workpc.redhat.com:8283/ocsp/agent/ocsp
>> Secure EE Port =
>> https://alee-workpc.redhat.com:8283/ocsp/ee/ocsp
>> Secure Admin Port =
>> https://alee-workpc.redhat.com:8283/ocsp/services
>> PKI Console Port = pkiconsole
>> https://alee-workpc.redhat.com:8283/ocsp
>> Tomcat Port = 8285 (for shutdown)
>>
>> Looks like you are not parsing the server.conf correctly.
>>
>>
>> On Wed, 2012-12-19 at 12:29 -0500, Ade Lee wrote:
>>> I found the following issues:
>>>
>>> Issue 1:
>>>
>>> Lets say I have the following setup:
>>> instance A with subsystems CA, KRA, OCSP
>>> instance B with subsystem CA, KRA
>>>
>>> Then for instance B, I see the following error message:
>>>
>>> grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or
>>> directory
>>> pki-tomcat27 Configuration Definitions not found for ocsp
>>>
>>> It appears that if any instance has a subsystem, then it is assumed
>>> that
>>> all instances have that subsystem because you use a global list of
>>> subsystems.
>>>
>>> Issue 2:
>>>
>>> This may be a pkidestroy problem. I did a pkidestroy of the OCSP on
>>> instance A. Now I see the following:
>>>
>>> [CA Status Definitions]
>>> Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca
>>> Secure Agent Port =
>>> https://alee-workpc.redhat.com:8223/ca/agent/ca
>>> Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca
>>> Secure Admin Port =
>>> https://alee-workpc.redhat.com:8223/ca/services
>>> EE Client Auth Port =
>>> https://alee-workpc.redhat.com:8223/ca/eeca/ca
>>> PKI Console Port = pkiconsole
>>> https://alee-workpc.redhat.com:8223/ca
>>> Tomcat Port = 8225 (for shutdown)
>>>
>>> [DRM Status Definitions]
>>> Unsecure Port =
>>> http://alee-workpc.redhat.com:8220/kra/ee/kra
>>> Secure Agent Port =
>>> https://alee-workpc.redhat.com:8223/kra/agent/kra
>>> Secure EE Port =
>>> https://alee-workpc.redhat.com:8223/kra/ee/kra
>>> Secure Admin Port =
>>> https://alee-workpc.redhat.com:8223/kra/services
>>> PKI Console Port = pkiconsole
>>> https://alee-workpc.redhat.com:8223/kra
>>> Tomcat Port = 8225 (for shutdown)
>>> Unsecure Port =
>>> http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp
>>> Secure Agent Port =
>>> https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp
>>> Secure EE Port =
>>> https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp
>>> Secure Admin Port =
>>> https://alee-workpc.redhat.com:8223/ocsp/services
>>> PKI Console Port = pkiconsole
>>> https://alee-workpc.redhat.com:8223/ocsp
>>> Tomcat Port = 8225 (for shutdown)
>>>
>>> That is -- I still see definitions from the removed OCSP. Ditto if I
>>> remove the KRA.
>>>
>>> Maybe this is a weird instance. Still testing ..
>>>
>>>
>>>
>>> On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote:
>>>> The attached patch addresses the following PKI issue:
>>>> * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in
>>>> 'pkidaemon' . . .
>>>>
>>>> _______________________________________________
>>>> 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 --------------
An HTML attachment was scrubbed...
URL:
From jmagne at redhat.com Fri Dec 21 22:46:54 2012
From: jmagne at redhat.com (John Magne)
Date: Fri, 21 Dec 2012 17:46:54 -0500 (EST)
Subject: [Pki-devel] Review Request: CMC ECC support
In-Reply-To: <50D1462B.9090206@redhat.com>
Message-ID: <1671068218.50795685.1356130014374.JavaMail.root@redhat.com>
Review Comments:
PKCS10Client.java
1. Typo, I think:
50 + System.out.println(" -x \n");
2. When parsing the command line args, it looks like we assume an even number or args, with the first arg being the switch and the second one being the value.
When you check the switch, there is no code to handle the case when the switch is not in the list. Also, it appears that not every value is checked. For instance, if an ecc curve is specified, I don't see a check for null.
3. We have the following piece of code in two places near each other:
if (dbdir == null)
141 dbdir = ".";
4. The following block:
try {
170 + token.login(pass);
171 + System.out.println("PKCS10Client: token "+ tokenName + " logged in...");
172 + } catch (Exception e) {
173 + System.out.println("PKCS10Client: login Exception: " + e.toString());
174 + if (!token.isLoggedIn()) {
175 + System.out.println("PKCS10Client: token not logged in, calling initPassword...");
176 + token.initPassword(pass, pass);
177 + }
178 + }
What are we doing here? If the password is wrong, should we not bomb out?
5. Code:
if (alg.equals("rsa")) {
182 + KeyPairGenerator kg = token.getKeyPairGenerator(KeyPairAlgorithm.RSA);
183 + kg.initialize(rsa_keylen);
184 + pair = kg.genKeyPair();
185 + } else if (alg.equals("ec")) {
186 + // used with SSL server cert that doe
What if the alg is some bogus value? The tool seems to happily skip over the entire block and keep going. Maybe some quick check?
6. certRequest = new CertificationRequest(certReqInfo,
If certRequest is null, we just log the fact to the screen but keep going.
7. PublicKey pubk = pair.getPublic();
Here , I do not think we ever check to see if "pair" is generated without a null. Maybe that is taken care of with the exceptions. But, also "pubk" is used later without a check for null.
8. Same as #6, with the value of "certReq".
CRMFPopClient.java
1. Check for the same argument parsing concerts as in the previous tool.
2. This check here:
try {
599 + CryptoManager.initialize( DB_DIR );
600 + } catch (Exception e) {
601 + // it is ok if it is already initialized
602 + System.out.println("CRMFPopClient: INITIALIZATION ERROR: " + e.toString());
603 + //return;
604 + }
Is it possible this would fail for some other reason besides that it was already initialized?
3. Same concern in the previous tool about what happens when token.login fails.
CMCRequest.java
1. Same concern here about checking the password.
HttpClient.java
1. This code:
+ X509Certificate cert =
1803 + cm.findCertByNickname(certname.toString());
1804 if (cert == null)
1805 System.out.println("client cert is null");
1806 else
1807 System.out.println("client cert is not null");
Do we care if there is no client cert? The code proceeds happily from this point on.
----- Original Message -----
From: "Christina Fu"
To: pki-devel at redhat.com
Sent: Tuesday, 18 December, 2012 8:44:27 PM
Subject: Re: [Pki-devel] Review Request: CMC ECC support
Please find a newer patch which now also includes support for CMC
revocation within the CMCRequest tool and op flags for EC key generation
in CRMFPopClient and PKCS10Client.
https://fedorahosted.org/pki/ticket/362
You will also find various Examples on how to test different scenarios
in regards to CMC request issuance.
thanks,
Christina
On 12/11/2012 04:51 PM, Christina Fu wrote:
> The following code is ready for review for task
> https://fedorahosted.org/pki/ticket/362
> Feature: CMC ECC
> which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well
> as CMC Response checking support needed HTTPClient ECC support.
> It should inherently fix the following existing bugs:
> https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC
> CRMF
> https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC
> revoke
>
> attachment:
> https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff
>
> Code changes involve both server and several tools.
>
> I will do some writeup and provide example on how to test in the task
> comment later.
>
> thanks!
> Christina
>
> _______________________________________________
> 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