[JBoss JIRA] (SHRINKRES-194) Multi-module gradle project support
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-194?page=com.atlassian.jira.plu... ]
Karel Piwko updated SHRINKRES-194:
----------------------------------
Fix Version/s: 2.2.0-alpha-3
> Multi-module gradle project support
> -----------------------------------
>
> Key: SHRINKRES-194
> URL: https://issues.jboss.org/browse/SHRINKRES-194
> Project: ShrinkWrap Resolvers
> Issue Type: Requirement
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.0-alpha-2
> Reporter: Michal Matloka
> Assignee: Michal Matloka
> Fix For: 2.2.0-alpha-3
>
>
> Issue from github https://github.com/mmatloka/arquillian-gradle-sample/issues/1:
> {quote}
> Hi,
> I'm very glad for your gradle resolver. However, we have multi project setup in which this code fails with an ArrayIndexOutOfBoundException
> {code}
> final GradleProject gradleProject = projectConnection.getModel(GradleProject.class);
> final File buildDir = new File(projectDir, "build");
> final File libsDir = new File(buildDir, "libs");
> final File result = libsDir.listFiles(new FilenameFilter() {
> @Override
> public boolean accept(final File dir, final String name) {
> return name.startsWith(gradleProject.getName());
> }
> })[0];
> {code}
> This is imho due to the fact that the gradleProject above holds the multi project but the arquillian tests are contained (and should be contained) in the sub project (*server). There the predicate will never be true and the [0] with end up in an exception.
> I think you can either do a deep search to also get the sub project jars or more accurately resolve the project the tests are in. If you need help let me know.
> Best,
> Maik
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-194) Multi-module gradle project support
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-194?page=com.atlassian.jira.plu... ]
Karel Piwko commented on SHRINKRES-194:
---------------------------------------
Fixed in https://github.com/shrinkwrap/resolver/commit/b14a8ad338c6677425e9d378896...
> Multi-module gradle project support
> -----------------------------------
>
> Key: SHRINKRES-194
> URL: https://issues.jboss.org/browse/SHRINKRES-194
> Project: ShrinkWrap Resolvers
> Issue Type: Requirement
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.0-alpha-2
> Reporter: Michal Matloka
> Assignee: Michal Matloka
> Fix For: 2.2.0-alpha-3
>
>
> Issue from github https://github.com/mmatloka/arquillian-gradle-sample/issues/1:
> {quote}
> Hi,
> I'm very glad for your gradle resolver. However, we have multi project setup in which this code fails with an ArrayIndexOutOfBoundException
> {code}
> final GradleProject gradleProject = projectConnection.getModel(GradleProject.class);
> final File buildDir = new File(projectDir, "build");
> final File libsDir = new File(buildDir, "libs");
> final File result = libsDir.listFiles(new FilenameFilter() {
> @Override
> public boolean accept(final File dir, final String name) {
> return name.startsWith(gradleProject.getName());
> }
> })[0];
> {code}
> This is imho due to the fact that the gradleProject above holds the multi project but the arquillian tests are contained (and should be contained) in the sub project (*server). There the predicate will never be true and the [0] with end up in an exception.
> I think you can either do a deep search to also get the sub project jars or more accurately resolve the project the tests are in. If you need help let me know.
> Best,
> Maik
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-194) Multi-module gradle project support
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-194?page=com.atlassian.jira.plu... ]
Karel Piwko updated SHRINKRES-194:
----------------------------------
Affects Version/s: 2.2.0-alpha-2
> Multi-module gradle project support
> -----------------------------------
>
> Key: SHRINKRES-194
> URL: https://issues.jboss.org/browse/SHRINKRES-194
> Project: ShrinkWrap Resolvers
> Issue Type: Requirement
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.0-alpha-2
> Reporter: Michal Matloka
> Assignee: Michal Matloka
>
> Issue from github https://github.com/mmatloka/arquillian-gradle-sample/issues/1:
> {quote}
> Hi,
> I'm very glad for your gradle resolver. However, we have multi project setup in which this code fails with an ArrayIndexOutOfBoundException
> {code}
> final GradleProject gradleProject = projectConnection.getModel(GradleProject.class);
> final File buildDir = new File(projectDir, "build");
> final File libsDir = new File(buildDir, "libs");
> final File result = libsDir.listFiles(new FilenameFilter() {
> @Override
> public boolean accept(final File dir, final String name) {
> return name.startsWith(gradleProject.getName());
> }
> })[0];
> {code}
> This is imho due to the fact that the gradleProject above holds the multi project but the arquillian tests are contained (and should be contained) in the sub project (*server). There the predicate will never be true and the [0] with end up in an exception.
> I think you can either do a deep search to also get the sub project jars or more accurately resolve the project the tests are in. If you need help let me know.
> Best,
> Maik
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-195) activeProfiles element from settings.xml seems to be ignored, property override not working
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-195?page=com.atlassian.jira.plu... ]
Karel Piwko commented on SHRINKRES-195:
---------------------------------------
Could you please check if that affects 2.1.0 or 2.1.1 version as well?
> activeProfiles element from settings.xml seems to be ignored, property override not working
> -------------------------------------------------------------------------------------------
>
> Key: SHRINKRES-195
> URL: https://issues.jboss.org/browse/SHRINKRES-195
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: impl-maven
> Affects Versions: 2.0.2
> Environment: Win7 x64
> JDK7u51
> Reporter: Falko M.
> Priority: Minor
>
> See:
> http://maven.apache.org/settings.html#Active_Profiles
> On the command line (mvn), the element is evaluated as expected and the specified profiles are activated but when I load the very same pom.xml via {{Maven.resolver().offline().loadPomFromFile(...)}}, the respective profiles are ignored, as it seems.
> I came accross this issue when I wanted to override a property from pom.xml in settings.xml and {{ParsedPomFile.getProperties()}} kept returning the non-overriden value.
> Notes:
> - the following in settings.xml *does work*:
> {noformat}
> <activation>
> <activeByDefault>true</activeByDefault>
> </activation>
> {noformat}
> - a new property defined in a settings.xml profile also doesn't show up in {{ParsedPomFile.getProperties()}} which seems to prove that the profile is not actived
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml
by Rafał Gała (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ]
Rafał Gała edited comment on SHRINKRES-146 at 8/25/14 3:23 AM:
---------------------------------------------------------------
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
are not identical hashes.
was (Author: wujaszek):
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
> Encrypted password support forces presence of settings-security.xml
> -------------------------------------------------------------------
>
> Key: SHRINKRES-146
> URL: https://issues.jboss.org/browse/SHRINKRES-146
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0-beta-4, 2.0.0
> Reporter: Falko M.
> Assignee: Andrew Rubinger
>
> This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories".
> As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown:
> {code}
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven.
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 80 more
> {code}
> This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed.
> As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml
by Rafał Gała (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ]
Rafał Gała edited comment on SHRINKRES-146 at 8/25/14 3:09 AM:
---------------------------------------------------------------
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
was (Author: wujaszek):
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
> Encrypted password support forces presence of settings-security.xml
> -------------------------------------------------------------------
>
> Key: SHRINKRES-146
> URL: https://issues.jboss.org/browse/SHRINKRES-146
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0-beta-4, 2.0.0
> Reporter: Falko M.
> Assignee: Andrew Rubinger
>
> This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories".
> As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown:
> {code}
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven.
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 80 more
> {code}
> This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed.
> As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml
by Rafał Gała (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ]
Rafał Gała edited comment on SHRINKRES-146 at 8/25/14 3:09 AM:
---------------------------------------------------------------
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password>
is not the same hash.
was (Author: wujaszek):
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
> Encrypted password support forces presence of settings-security.xml
> -------------------------------------------------------------------
>
> Key: SHRINKRES-146
> URL: https://issues.jboss.org/browse/SHRINKRES-146
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0-beta-4, 2.0.0
> Reporter: Falko M.
> Assignee: Andrew Rubinger
>
> This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories".
> As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown:
> {code}
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven.
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 80 more
> {code}
> This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed.
> As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml
by Rafał Gała (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ]
Rafał Gała edited comment on SHRINKRES-146 at 8/25/14 3:09 AM:
---------------------------------------------------------------
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
was (Author: wujaszek):
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password>
is not the same hash.
> Encrypted password support forces presence of settings-security.xml
> -------------------------------------------------------------------
>
> Key: SHRINKRES-146
> URL: https://issues.jboss.org/browse/SHRINKRES-146
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0-beta-4, 2.0.0
> Reporter: Falko M.
> Assignee: Andrew Rubinger
>
> This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories".
> As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown:
> {code}
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven.
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 80 more
> {code}
> This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed.
> As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml
by Rafał Gała (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ]
Rafał Gała edited comment on SHRINKRES-146 at 8/25/14 3:09 AM:
---------------------------------------------------------------
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
was (Author: wujaszek):
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
> Encrypted password support forces presence of settings-security.xml
> -------------------------------------------------------------------
>
> Key: SHRINKRES-146
> URL: https://issues.jboss.org/browse/SHRINKRES-146
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0-beta-4, 2.0.0
> Reporter: Falko M.
> Assignee: Andrew Rubinger
>
> This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories".
> As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown:
> {code}
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven.
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 80 more
> {code}
> This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed.
> As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SHRINKRES-146) Encrypted password support forces presence of settings-security.xml
by Rafał Gała (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-146?page=com.atlassian.jira.plu... ]
Rafał Gała edited comment on SHRINKRES-146 at 8/25/14 3:07 AM:
---------------------------------------------------------------
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\\}</password>
is not the same hash.
was (Author: wujaszek):
Escaping curly bracket solves the problem with Shrinkwrap, but adding "\" before closing bracket changes the password hash and then it is incorrectly decoded by Maven.
For example:
<password>{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=}</password>
and
<password>\{/XFp4jLOtEMHmqV6niPdSZ1cf/ck/gxDk0PBgjgZkLY=\}</password>
is not the same hash.
> Encrypted password support forces presence of settings-security.xml
> -------------------------------------------------------------------
>
> Key: SHRINKRES-146
> URL: https://issues.jboss.org/browse/SHRINKRES-146
> Project: ShrinkWrap Resolvers
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0-beta-4, 2.0.0
> Reporter: Falko M.
> Assignee: Andrew Rubinger
>
> This problem is caused by SHRINKRES-38 "Support encrypted passwords for password protected repositories".
> As soon {{MavenSettingsBuilder}} finds passwords in the settings file, it apprently assumes that they are encrypted with the master password which is defined in {{settings-security.xml}}. When the file cannot be found an exception is thrown:
> {code}
> org.jboss.shrinkwrap.resolver.api.InvalidConfigurationFileException: Unable to get security configuration from C:\Users\U115417\.m2\settings-security.xml. Please define path to the settings-security.xml file via -Dorg.apache.maven.security-settings, or put it the the default location defined by Maven.
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.getMaster(MavenSecurityDispatcher.java:171)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSecurityDispatcher.decrypt(MavenSecurityDispatcher.java:96)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:92)
> at org.jboss.shrinkwrap.resolver.impl.maven.internal.decrypt.MavenSettingsDecrypter.decrypt(MavenSettingsDecrypter.java:60)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.decryptPasswords(MavenSettingsBuilder.java:223)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildSettings(MavenSettingsBuilder.java:186)
> at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenSettingsBuilder.buildDefaultSettings(MavenSettingsBuilder.java:113)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.<init>(MavenWorkingSessionImpl.java:123)
> at org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemImpl.<init>(MavenResolverSystemImpl.java:43)
> ... 80 more
> {code}
> This is not correct as passwords can be defined without encryption and in this case no {{settings-security.xml}} file is needed.
> As we use server-side hashed passwords (without client-side encryption), this is a deal breaker for our project as you cannot work around this problem by just creating an empty file or a dummy password.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months