Re: [ANNOUNCE] Welcoming Ted Kirby as a Geronimo Committer
Congratulations! 2008/6/19, Donald Woods [EMAIL PROTECTED]: I'd like to welcome Ted Kirby as Geronimo's newest committer. Ted, keep up all the great work on the Eclipse Plugin and welcome aboard! -Donald
Re: [DISCUSS] Create a Ready for Geronimo page under Community
2008/2/8, Donald Woods [EMAIL PROTECTED]: To foster more projects to test and support Geronimo, I'd like to float the idea of creating a new page under the Community navigation section on our home page called - Ready for Geronimo The content of this page would be - - known applications/frameworks that run on Geronimo - third-party provided plug-ins (like Liferay) - Geronimo provided plug-ins (like Roller) JDKs? :) SY, Alexey
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563019#action_12563019 ] Alexey Petrenko commented on GERONIMO-3757: --- I think it worth to move this discussion to dev list to get more opinions. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3757-2.0.patch, GERONIMO-3757-2.1.patch, Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562916#action_12562916
]
Alexey Petrenko commented on GERONIMO-3757:
---
{quote}
The reason for the above piece of code is that defaultType and the
corresponding algorithm name got from the Service need not be of same case. For
e.g. defaultType is jks where as the one we get from available types is
JKS. Nothing more
{quote}
I thought about this. :)
Thanks for the explanation.
+1 for commit.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console, security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Assignee: Vamsavardhana Reddy
Fix For: 2.0.x, 2.1
Attachments: GERONIMO-3757-2.0.patch, GERONIMO-3757-2.1.patch,
Geronimo-3757-trunk.patch, Geronimo-3757.patch, Geronimo-3757.patch,
GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
configuration option, keystoreType, that would allow to change the keystore
type through config.xml without recompilation, like this:
module name=org.apache.geronimo.configs/server-security-config/2.0.2/car
gbean name=geronimo-default
attribute name=keystoreTypePKCS12/attribute
attribute
name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute
/gbean
/module
This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562692#action_12562692
]
Alexey Petrenko commented on GERONIMO-3757:
---
{quote}
1. defaultType can not be null. Ideally,
KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any
exceptions.
{quote}
Yes, we expect that KeyStore.getDefaultType() will not throw an exception.
But the code
{code:java}
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
{code}
assumes that it is possible that there will not be default type in the type
list. Otherwise it can be changed to simple
{code:java}
defaultType =KeyStore.getDefaultType();
{quote}
2. The keystoreTypes is the list of types that will be shown for selection
while creating a keystore using Keystores portlet. It does not matter what the
defaultType is. If defaultType is in keystoreTypes, it will be selected,
otherwise the first one in the list will be selected. We are using these to
prevent users from selecting a keystore type that can not have an empty
keystore.
{quote}
ok. thanks.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
Geronimo-3757.patch, GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
configuration option, keystoreType, that would allow to change the keystore
type through config.xml without recompilation, like this:
module name=org.apache.geronimo.configs/server-security-config/2.0.2/car
gbean name=geronimo-default
attribute name=keystoreTypePKCS12/attribute
attribute
name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute
/gbean
/module
This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562692#action_12562692
]
cap edited comment on GERONIMO-3757 at 1/25/08 1:32 PM:
{quote}
1. defaultType can not be null. Ideally,
KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any
exceptions.
{quote}
Yes, we expect that KeyStore.getDefaultType() will not throw an exception.
But the code
{code:java}
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
{code}
assumes that it is possible that there will not be default type in the type
list. Otherwise it can be changed to simple
{code:java}
defaultType = KeyStore.getDefaultType();
{code}
{quote}
2. The keystoreTypes is the list of types that will be shown for selection
while creating a keystore using Keystores portlet. It does not matter what the
defaultType is. If defaultType is in keystoreTypes, it will be selected,
otherwise the first one in the list will be selected. We are using these to
prevent users from selecting a keystore type that can not have an empty
keystore.
{quote}
ok. thanks.
was (Author: cap):
{quote}
1. defaultType can not be null. Ideally,
KeyStore.getInstance(KeyStore.getDefaultType()) is expected to not throw any
exceptions.
{quote}
Yes, we expect that KeyStore.getDefaultType() will not throw an exception.
But the code
{code:java}
for(String type: tempKeystoreTypes) {
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
break;
}
}
{code}
assumes that it is possible that there will not be default type in the type
list. Otherwise it can be changed to simple
{code:java}
defaultType =KeyStore.getDefaultType();
{quote}
2. The keystoreTypes is the list of types that will be shown for selection
while creating a keystore using Keystores portlet. It does not matter what the
defaultType is. If defaultType is in keystoreTypes, it will be selected,
otherwise the first one in the list will be selected. We are using these to
prevent users from selecting a keystore type that can not have an empty
keystore.
{quote}
ok. thanks.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757-trunk.patch, Geronimo-3757.patch,
Geronimo-3757.patch, GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
configuration option, keystoreType, that would allow to change the keystore
type through config.xml without recompilation, like this:
module name=org.apache.geronimo.configs/server-security-config/2.0.2/car
gbean name=geronimo-default
attribute name=keystoreTypePKCS12/attribute
attribute
name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute
/gbean
/module
This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562179#action_12562179
]
Alexey Petrenko commented on GERONIMO-3757:
---
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
byte []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
=== cut ===
This implementation will save few processor ticks and few object creations.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757.patch, Geronimo-3757.patch,
GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
configuration option, keystoreType, that would allow to change the keystore
type through config.xml without recompilation, like this:
module name=org.apache.geronimo.configs/server-security-config/2.0.2/car
gbean name=geronimo-default
attribute name=keystoreTypePKCS12/attribute
attribute
name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute
/gbean
/module
This issue if a follow up to GERONIMO-2015.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562179#action_12562179
]
cap edited comment on GERONIMO-3757 at 1/24/08 11:34 AM:
-
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
{noformat}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
byte []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{noformat}
=== cut ===
This implementation will save few processor ticks and few object creations.
was (Author: cap):
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
byte []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
=== cut ===
This implementation will save few processor ticks and few object creations.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757.patch, Geronimo-3757.patch,
GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
configuration option,
[jira] Issue Comment Edited: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562179#action_12562179
]
cap edited comment on GERONIMO-3757 at 1/24/08 11:58 AM:
-
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
{noformat}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
char []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{noformat}
=== cut ===
This implementation will save few processor ticks and few object creations.
was (Author: cap):
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
{noformat}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
byte []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{noformat}
=== cut ===
This implementation will save few processor ticks and few object creations.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757.patch, Geronimo-3757.patch,
GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562196#action_12562196 ] Alexey Petrenko commented on GERONIMO-3757: --- I also curious about CreateKeystoreHandler.defaultType variable... 1. As far as I understood from the code you want this variable to be null if KeyStore.getDefaultType() is not in the list of available keystore types. Is this possible? From the other hand null type treated as KeyStore.getDefaultType() later in the code. It is a bit confusing for me... 2. How will we handle situation if defaultType variable is not null but it is impossible to create empty store for this type and the type will be removed from the list on next step? KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757.patch, Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3757) KeyStore type can't be changed
[
https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562179#action_12562179
]
cap edited comment on GERONIMO-3757 at 1/24/08 12:07 PM:
-
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
{code:java}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
char []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{code}
=== cut ===
This implementation will save few processor ticks and few object creations.
was (Author: cap):
Guys,
I suggest to change CreateKeystoreHandler static initializer to something like
that:
=== cut ===
{noformat}
static {
// Get all the KeyStore algorithms supported.
keystoreTypes = new HashSetString();
Provider[] providers = Security.getProviders();
char []emptystore = emptystore.toCharArray();
for(Provider provider: providers) {
for(Provider.Service service: provider.getServices()) {
if(service.getType().equals(KeyStore)) {
// Not all types of keystores can be saved to disk when
empty.
// Do not add those types that will fail creation of an
empty keystore.
ByteArrayOutputStream baos = null;
try {
KeyStore ks = KeyStore.getInstance(type);
ks.load(null);
baos = new ByteArrayOutputStream();
ks.store(baos, emptystore);
String type = service.getAlgorithm();
keystoreTypes.add(type);
if(type.equalsIgnoreCase(KeyStore.getDefaultType())) {
defaultType = type;
}
} catch(Throwable t) {
} finally {
if(baos != null) {
try {baos.close();} catch(Exception ignored){}
}
}
}
}
}
}
{noformat}
=== cut ===
This implementation will save few processor ticks and few object creations.
KeyStore type can't be changed
--
Key: GERONIMO-3757
URL: https://issues.apache.org/jira/browse/GERONIMO-3757
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.2, 2.0.x, 2.1
Reporter: Vasily Zakharov
Attachments: Geronimo-3757.patch, Geronimo-3757.patch,
GERONIMO-3757.patch
For now (r612905), Geronimo is hardcoded to use JKS keystore type, which
prevents Geronimo from running on Harmony or other JDKs that have no JKS
implementation:
org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635:
KeyStore tempKeystore = KeyStore.getInstance(JKS);
org.apache.geronimo.security.keystore.FileKeystoreManager, line 364:
KeyStore keystore =
KeyStore.getInstance(FileKeystoreInstance.JKS);
To workaround this issue, one can change JKS to KeyStore.getDefaultType()
(this returns BKS for Harmony) or particular other keystore type, but this
requires source recompilation. Replacing
var/security/keystores/geronimo-default with the proper keystore type file is
not a problem.
A proper solution seems to apply the fix above to use the JDK-default
keystore type, and provide FileKeystoreInstance with an additional
Re: [YOKO] premature tools deletion?
+1 for keeping tools. 2008/1/17, Alan D. Cabrera [EMAIL PROTECTED]: I was wondering if we prematurely deleted tools. It would be nice to have our own IDL compiler. I was thinking that we could move tools to a dir in the sandbox for someone to pick up. Thoughts? Regards, Alan
Re: [YOKO] Yoko web site
2008/1/17, Joseph Leong [EMAIL PROTECTED]: Hi there Alan, In terms of starting a Wiki, there are several options out there... just to name a few popular ones: Confluence http://www.atlassian.com/software/confluence/ Media Wiki http://www.mediawiki.org/wiki/MediaWiki Doku Wiki http://wiki.splitbrain.org/wiki:dokuwiki PmWiki http://www.pmwiki.org/ And Apach JSPWiki :) http://incubator.apache.org/jspwiki/ Is it possible to run Tomcat for wiki? SY, Alexey
Re: MailGBean/JNDI problem on Harmony
Nice. But it starts with patched key store as far as I understand... right?
SY, Alexey
https://issues.apache.org/jira/browse/GERONIMO-2015
2008/1/16, Zakharov, Vasily M [EMAIL PROTECTED]:
Sorry for disturbing, I've just found out the cause for this issue - I
had one extra property in config.xml. If namingFactoryInitial
specification is removed, and namingFactoryUrlPkgs specification is
retained, the problem is resolved, and Geronimo starts fine on Harmony.
Vasily
-Original Message-
From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 8:53 PM
To: dev@geronimo.apache.org
Subject: MailGBean/JNDI problem on Harmony
Hi, all,
I'm found a problem with MailGBean on Harmony due to of JNDI
configuration, and I'm asking for help to understand how to deal with
that problem. The problem would occur on any JDK lacking Sun
implementation of JNDI RMI Registry provider
(com.sun.jndi.rmi.registry.RegistryContext). The problem occurs at
startup and looks as follows:
java.lang.IllegalArgumentException: Cannot bind to RMI Registry object
that is neither Remote nor Reference nor Referenceable
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.getStateTo
Bind(RegistryContext.java:618)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:266)
at
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext.bind(Regis
tryContext.java:280)
at javax.naming.InitialContext.bind(InitialContext.java:411)
at
org.apache.geronimo.mail.MailGBean.doStart(MailGBean.java:385)
The investigation shows the following difference of MailGBean code
operation on Sun and Harmony:
On Sun, the InitialContext.getEnvironment() is empty, and
InitialContext.lookup() returns
org.apache.geronimo.gjndi.GlobalContextGBean, and
InitialContext.getNameParser() returns
org.apache.xbean.naming.context.ContextUtil$SimpleNameParser.
On Harmony, this works much differently -
InitialContext.getEnvironment() contains the JNDI properties specified
in config.xml, and InitialContext.lookup() returns
org.apache.harmony.jndi.provider.rmi.registry.RegistryContext, and
InitialContext.getNameParser() returns
org.apache.harmony.jndi.provider.rmi.registry.AtomicNameParser.
This causes the error above.
I had to specify the respective JNDI properties in config.xml for
JMXConnector to start normally, as follows:
module name=org.apache.geronimo.configs/rmi-naming/2.0.2/car
gbean name=NamingProperties
attribute
name=namingFactoryInitialorg.apache.harmony.jndi.provider.rmi.registr
y.RegistryContextFactory/attribute
attribute
name=namingFactoryUrlPkgsorg.apache.harmony.jndi.provider/attribute
attribute name=namingProviderUrlrmi://${ServerHostname}:${NamingPort
+ PortOffset}/attribute
/gbean
Probably this is wrong to configure JNDI this way, as it overrides
Geronimo internal naming mechanisms?
Maybe org.apache.geronimo.gjndi.GlobalContextGBean needs to be tweaked
to find the proper JNDI RMI Registry provider by other means than
standard JNDI properties?
I'd be happy to hear any ideas, considerations or suggestions on this
issue.
Thank you very much!
Vasily Zakharov
Intel ESSD
---
Re: progress bar at Geronimo startup
Hi, Jarek.
Just few comments about the patch...
As far as understand each module appears only once in modules array.
And the objects there are the same with coming to moduleLoading,
moduleLoaded, moduleStarting and moduleStarted methods.
If I'm correct here then I suggest to change the following statements
a little...
=== original ===
for (int i = 0; i modules.length; i++) {
if (modules[i].equals(module)) {
moduleStatus[i] = STATUS_LOADED;
}
}
=== original ===
=== suggested ===
for (int i = 0; i modules.length; i++) {
if (modules[i] == module) {
moduleStatus[i] = STATUS_LOADED;
break;
}
}
=== suggested ===
Not very significant change but will boost startup performance a
little (probably very little :) for big list of modules.
SY, Alexey
2008/1/16, Jarek Gawor [EMAIL PROTECTED]:
Folks,
A few times before I've ran into some problems with the progress bar
displayed at Geronimo startup as I had a lot of modules installed. I
described the problem in
https://issues.apache.org/jira/browse/GERONIMO-3725. I also just
attached to the bug report a patch with a new and simpler progress bar
hat does not suffer from the same problem as the existing bar but at
the same time it does not it display the same detail info as the
existing bar. I tired to explain this difference in the bug report.
So, any thoughts/objections on replacing the existing progress bar
with the one I attached to the bug report?
Thanks,
Jarek
[jira] Assigned: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Petrenko reassigned GERONIMO-2015: - Assignee: Alexey Petrenko Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: https://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Reporter: Nikolay Chugunov Assignee: Alexey Petrenko Fix For: Wish List Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, jksToPKCS12.patch, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.0.2 starts on Harmony!
Great news, Vasily! What do you mean by HTTP interface works badly? Slow? Exceptions? What platform are you using? Linux or Windows? As far as I understood you already got a patch for GERONIMO-3757. If so could you please attach it to the issue? :) I also think that it would be nice to add the list of Harmony and Geronimo issues related to Geronimo on Harmony to the wiki page you have created. Thanks in advance. SY, Alexey 2008/1/18, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Well, finally I can say Geronimo 2.0.2 starts and works on Apache Harmony! Some steps yet need to be taken for that to happen - see [1] for details. Some issues were overcome, some workarounded, and some just hotfixed and wait for their proper resolution, like GERONIMO-3757. Three important problems that still need investigation are: - HTTP interface works badly (HTTPS works fine). - The application takes up all the CPU resources on both cores I have available so the machine is 100% busy. - The application takes up all the memory specified in -Xms option. Otherwise, I was able to browse the console freely and even deploy SPECjAppServer2004. No serious load was tested however. Vasily Zakharov Intel ESSD [1] http://cwiki.apache.org/confluence/display/GMOxDOC20/Apache+Harmony
[jira] Closed: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Petrenko closed GERONIMO-2015. - Resolution: Won't Fix Changing default key store from JKS to PKCS12 or something else will be too strong move at the moment. It makes much more sense to make this feature configurable. Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: https://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Reporter: Nikolay Chugunov Assignee: Alexey Petrenko Fix For: Wish List Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, jksToPKCS12.patch, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO]
I'm +1 for 1.0 release too. I've reviewed japitool results for ORB area of Harmony and I have not find any differences which are result of 1.4 compatibility of Yoko. So it looks like there is no difference for Harmony in this case. But yes, Harmony is 1.5 (however it has 1.6 branch :) and any 1.5 compatible code is acceptable for it. 2008/1/15, Lars Kühne [EMAIL PROTECTED]: On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote: On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote: What cleanup steps need to be taken with the yoko code now that it's been made a subproject in Geronimo? The first obvious one would be to remove the non-core components from the trunk. The second would be to remove the incubating from the version names. Agreed +1 Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency to 1.5 since yoko entered the incubator? We shouldn't change the required JDK in a point release, so this seems like a good time to revisit this decision. The current code was never made into an official Yoko release. Should we attempt to get this out as an official v1 release as soon as the basic cleanup is completed? I think that some people had some concerns about a release but I think that they were more focused on proper documentation and releasing a well rounded product. That was me. My concern wasn't so much about user docs but developer level documentation, see the Answer this question... yoko issues in jira. Those questions mostly about being able to attract new developers. It's my opinion that it's ok to release so long as the code is good enough. With that said, I would like to make a 1.0 release. Yes, the code could use some cleanup but it does pass certification and we can always improve things later, in another release. This of course assumes that we don't have to pay too much attention to backward compatibility. Does each follow-up version have to be a drop-in replacement of the first 1.0 release? Or is it OK to change ORB properties and such, as long as the changes are documented in the release notes (which is what I hope, but I don't know the requirements of Geronimo and Harmony)? It's OK from Harmony point of view. SY, Alexey
[jira] Commented: (GERONIMO-2015) Let's replace JKS to PKCS12 key store type
[ https://issues.apache.org/jira/browse/GERONIMO-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559433#action_12559433 ] Alexey Petrenko commented on GERONIMO-2015: --- If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose? We can specify keystore in configs or choose type from available on current VM. Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: https://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Reporter: Nikolay Chugunov Fix For: Wish List Attachments: jksToPKCS12-1.1.1.patch, JKSToPKCS12.java, jksToPKCS12.patch, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to change KeyStore type?
I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using config.xml, without source recompilation? I've browsed through the configuration options of geronimo-security gbean, a found no way for that. Should I provide a patch for that to be possible, would that be appropriate? Thank you! Vasily Zakharov Intel ESSD ---
Re: TSSConfigEditorTest requires SSL?
Probably we should change the test to let it choose from available protocols. SY, Alexey 2007/12/29, Jarek Gawor [EMAIL PROTECTED]: Try adding the following line to this test: corbaBean.getSslConfig().setProtocol(TLS); so the code looks like: corbaBean.setTssConfig(tss); corbaBean.getSslConfig().setProtocol(TLS); Jarek On Dec 27, 2007 12:48 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: David, Yes, Harmony supports TLS, but looking at the test code and configuration I couldn't guess a way how the test could be reconfigured for TLS. One of the reasons I'm asking is I now have greater than 99% pass rate for GUT v2.0.2 on Harmony, and this test is the last one about which I'm not sure if we have a bug in Harmony, or a bug in the test or it's just because Harmony doesn't have SSL and that's a known issue. Vasily -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 8:37 PM To: dev@geronimo.apache.org Subject: Re: TSSConfigEditorTest requires SSL? It has been a long time since I've worked with this test but I'm pretty sure that you are correct, the test sets up an SSL socket. I seem to recall that Harmony supports TLS?? From the stack trace I wonder if the problem is in Yoko. I'm definitely not a TLS expert, do you have any advice on how to fix this? thanks david jencks On Dec 27, 2007, at 10:33 AM, Zakharov, Vasily M wrote: Hi, all, I wonder if org.apache.geronimo.yoko.TSSConfigEditorTest test is SSL dependent? I'm trying to run Geronimo Unit Tests on Apache Harmony, and this test fails (with the stack below) for the reason I couldn't find out. Could that be because Harmony has no SSL implementation? SEVERE: Failure accepting connection for host=ecwm0vmzakhar/172.28.118.8, port=8050 java.io.IOException: Connection was closed at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake (SSLSocke tImpl.java:760) at org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake (SSLSo cketImpl.java:438) at org.apache.harmony.xnet.provider.jsse.SSLServerSocketImpl.accept (SSLServ erSocketImpl.java:256) at org.apache.yoko.orb.OCI.IIOP.Acceptor_impl.accept (Acceptor_impl.java:111 ) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun (GIOPServerSt arterThreaded.java:195) at org.apache.yoko.orb.OB.GIOPServerStarterThreaded$StarterThread.run (GIOPS erverStarterThreaded.java:34) Vasily Zakharov Intel ESSD --- Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Closed Joint Stock Company Intel A/O Registered legal address: 125252, Moscow, Russian Federation, Chapayevsky Per, 14. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
