honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/distribution/tools/plugin-cli/build.gradle

73 lines
2.9 KiB
Groovy
Raw Normal View History

Build: Move plugin cli and tests to distribution tool (#24220) The plugin cli currently resides inside the elasticsearch jar. This commit moves it into a plugin-cli jar. This is change alone is a no-op; it does not change anything about what is loaded at runtime. But it will allow easier testing (with fixtures in the future to test ES or maven installation), as well as eventually not loading these classes when starting elasticsearch.
2017-04-21 12:25:58 -04:00
/*
* Licensed to Elasticsearch under one or more contributor
* license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright
* ownership. Elasticsearch licenses this file to you under
* the Apache License, Version 2.0 (the "License"); you may
* not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
apply plugin: 'elasticsearch.build'
Verify signatures on official plugins (#30800) We sign our official plugins yet this is not well-advertised and not at all consumed during plugin installation. For plugins that are installed over the intertubes, verifying that the downloaded artifact is signed by our signing key would establish both integrity and validity of the downloaded artifact. The chain of trust here is simple: our installable artifacts (archive and package distributions) so that if a user trusts our packages via their signatures, and our plugin installer (which would be executing trusted code) verifies the downloaded plugin, then the user can trust the downloaded plugin too. This commit adds verification of official plugins downloaded during installation. We do not add verification for offline plugin installs; a user can download our signatures and verify the artifacts themselves. This commit also needs to solve a few interesting challenges. One of these is that we want the bouncy castle JARs on the classpath only for the plugin installer, but not for the runtime Elasticsearch. Additionally, we want these JARs to not be present for the JAR hell checks. To address this, we shift these JARs into a sub-directory of lib (lib/tools/plugin-cli) that is only loaded for the plugin installer, and in the plugin installer we filter any JARs in this directory from the JAR hell check.
2018-05-25 07:56:35 -04:00
archivesBaseName = 'elasticsearch-plugin-cli'
Build: Move plugin cli and tests to distribution tool (#24220) The plugin cli currently resides inside the elasticsearch jar. This commit moves it into a plugin-cli jar. This is change alone is a no-op; it does not change anything about what is loaded at runtime. But it will allow easier testing (with fixtures in the future to test ES or maven installation), as well as eventually not loading these classes when starting elasticsearch.
2017-04-21 12:25:58 -04:00
dependencies {
[Backport] Remove dependency substitutions 7.x (#42866) * Remove unnecessary usage of Gradle dependency substitution rules (#42773) (cherry picked from commit 12d583dbf6f7d44f00aa365e34fc7e937c3c61f7)
2019-06-04 16:50:23 -04:00
compileOnly project(":server")
compileOnly project(":libs:elasticsearch-cli")
Make plugin verification FIPS 140 compliant (#44266) This change makes the process of verifying the signature of official plugins FIPS 140 compliant by defaulting to use the BouncyCastle FIPS provider and adding a dependency to bcpg-fips that implement parts of openPGP in a FIPS compliant manner. In already FIPS 140 enabled environments that use the BouncyCastle FIPS provider, the bcfips dependency is redundant but doesn't cause an issue as it will be added only in the classpath of the cli-tools This is a backport of #44224
2019-07-12 07:34:15 -04:00
compile "org.bouncycastle:bcpg-fips:1.0.3"
compile "org.bouncycastle:bc-fips:1.0.1"
[Backport] Remove dependency substitutions 7.x (#42866) * Remove unnecessary usage of Gradle dependency substitution rules (#42773) (cherry picked from commit 12d583dbf6f7d44f00aa365e34fc7e937c3c61f7)
2019-06-04 16:50:23 -04:00
testCompile project(":test:framework")
Build: Move plugin cli and tests to distribution tool (#24220) The plugin cli currently resides inside the elasticsearch jar. This commit moves it into a plugin-cli jar. This is change alone is a no-op; it does not change anything about what is loaded at runtime. But it will allow easier testing (with fixtures in the future to test ES or maven installation), as well as eventually not loading these classes when starting elasticsearch.
2017-04-21 12:25:58 -04:00
testCompile 'com.google.jimfs:jimfs:1.1'
testCompile 'com.google.guava:guava:18.0'
}
Verify signatures on official plugins (#30800) We sign our official plugins yet this is not well-advertised and not at all consumed during plugin installation. For plugins that are installed over the intertubes, verifying that the downloaded artifact is signed by our signing key would establish both integrity and validity of the downloaded artifact. The chain of trust here is simple: our installable artifacts (archive and package distributions) so that if a user trusts our packages via their signatures, and our plugin installer (which would be executing trusted code) verifies the downloaded plugin, then the user can trust the downloaded plugin too. This commit adds verification of official plugins downloaded during installation. We do not add verification for offline plugin installs; a user can download our signatures and verify the artifacts themselves. This commit also needs to solve a few interesting challenges. One of these is that we want the bouncy castle JARs on the classpath only for the plugin installer, but not for the runtime Elasticsearch. Additionally, we want these JARs to not be present for the JAR hell checks. To address this, we shift these JARs into a sub-directory of lib (lib/tools/plugin-cli) that is only loaded for the plugin installer, and in the plugin installer we filter any JARs in this directory from the JAR hell check.
2018-05-25 07:56:35 -04:00
dependencyLicenses {
mapping from: /bc.*/, to: 'bouncycastle'
}
[Backport] Replace usages RandomizedTestingTask with built-in Gradle Test (#40978) (#40993) * Replace usages RandomizedTestingTask with built-in Gradle Test (#40978) This commit replaces the existing RandomizedTestingTask and supporting code with Gradle's built-in JUnit support via the Test task type. Additionally, the previous workaround to disable all tasks named "test" and create new unit testing tasks named "unitTest" has been removed such that the "test" task now runs unit tests as per the normal Gradle Java plugin conventions. (cherry picked from commit 323f312bbc829a63056a79ebe45adced5099f6e6) * Fix forking JVM runner * Don't bump shadow plugin version
2019-04-09 14:52:50 -04:00
test {
Build: Move plugin cli and tests to distribution tool (#24220) The plugin cli currently resides inside the elasticsearch jar. This commit moves it into a plugin-cli jar. This is change alone is a no-op; it does not change anything about what is loaded at runtime. But it will allow easier testing (with fixtures in the future to test ES or maven installation), as well as eventually not loading these classes when starting elasticsearch.
2017-04-21 12:25:58 -04:00
// TODO: find a way to add permissions for the tests in this module
systemProperty 'tests.security.manager', 'false'
}
Fix forbidden apis on FIPS (#33202) - third party audit detects jar hell with JDK so we disable it - jdk non portable in forbiddenapis detects classes being used from the JDK ( for fips ) that are not portable, this is intended so we don't scan for it on fips. - different exclusion rules for third party audit on fips Closes #33179
2018-08-29 10:43:40 -04:00
[Backport] Improve build configuration time (#42674)
2019-05-30 13:29:42 -04:00
thirdPartyAudit.onlyIf {
Fix forbidden apis on FIPS (#33202) - third party audit detects jar hell with JDK so we disable it - jdk non portable in forbiddenapis detects classes being used from the JDK ( for fips ) that are not portable, this is intended so we don't scan for it on fips. - different exclusion rules for third party audit on fips Closes #33179
2018-08-29 10:43:40 -04:00
// FIPS JVM includes manny classes from bouncycastle which count as jar hell for the third party audit,
// rather than provide a long list of exclusions, disable the check on FIPS.
[Backport] Improve build configuration time (#42674)
2019-05-30 13:29:42 -04:00
project.inFipsJvm == false
Make plugin verification FIPS 140 compliant (#44266) This change makes the process of verifying the signature of official plugins FIPS 140 compliant by defaulting to use the BouncyCastle FIPS provider and adding a dependency to bcpg-fips that implement parts of openPGP in a FIPS compliant manner. In already FIPS 140 enabled environments that use the BouncyCastle FIPS provider, the bcfips dependency is redundant but doesn't cause an issue as it will be added only in the classpath of the cli-tools This is a backport of #44224
2019-07-12 07:34:15 -04:00
}
/*
* these two classes intentionally use the following JDK internal APIs in order to offer the necessary
* functionality
*
* sun.security.internal.spec.TlsKeyMaterialParameterSpec
* sun.security.internal.spec.TlsKeyMaterialSpec
* sun.security.internal.spec.TlsMasterSecretParameterSpec
* sun.security.internal.spec.TlsPrfParameterSpec
* sun.security.internal.spec.TlsRsaPremasterSecretParameterSpec
* sun.security.provider.SecureRandom
*
*/
thirdPartyAudit.ignoreViolations(
'org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$CoreSecureRandom',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$BaseTLSKeyGeneratorSpi',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSKeyMaterialGenerator',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSKeyMaterialGenerator$2',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSMasterSecretGenerator',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSMasterSecretGenerator$2',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSPRFKeyGenerator',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSRsaPreMasterSecretGenerator',
'org.bouncycastle.jcajce.provider.ProvSunTLSKDF$TLSRsaPreMasterSecretGenerator$2'
)