[jira] [Updated] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Xia updated DELTASPIKE-1474:
--
Description:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method for better
security
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
was:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version 2.0"|
http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
> Inquiry Regarding Potential Inadequate Password-Based Encryption in
> DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
> --
>
> Key: DELTASPIKE-1474
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1474
> Project: DeltaSpike
> Issue Type: Improvement
>
[jira] [Updated] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Xia updated DELTASPIKE-1474:
--
Description:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version 2.0"|
http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
was:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
```java
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
```java
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
```
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
```java
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
[1][ "PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
> Inquiry Regarding Potential Inadequate Password-Based Encryption in
> DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
> --
>
> Key: DELTASPIKE-1474
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1474
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular
[jira] [Created] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
Yifan Xia created DELTASPIKE-1474:
-
Summary: Inquiry Regarding Potential Inadequate Password-Based
Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
Key: DELTASPIKE-1474
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1474
Project: DeltaSpike
Issue Type: Improvement
Security Level: public (Regular issues)
Reporter: Yifan Xia
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
```java
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
```java
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
```
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
```java
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
[1][ "PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided dependency {{tomcat-servlet-api}} be changed to
Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally and only within this single project)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided dependency {{tomcat-servlet-api}} be changed to
Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As a follow-up to DELTASPIKE-1472 I
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided dependency {{tomcat-servlet-api}} be changed to
Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Labels:
