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

75 lines
2.9 KiB
Groovy
Raw Normal View History

[7.x] Introduce type-safe and consistent pattern for handling build globals (#48818) This commit introduces a consistent, and type-safe manner for handling global build parameters through out our build logic. Primarily this replaces the existing usages of extra properties with static accessors. It also introduces and explicit API for initialization and mutation of any such parameters, as well as better error handling for uninitialized or eager access of parameter values. Closes #42042
2019-11-01 14:33:11 -04:00
import org.elasticsearch.gradle.info.BuildParams
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.
Disable thirdPartyAudit tests when running in a FIPS JVM (#49115) This fixes a regression introduced in #42042. The logic here was mistakenly inverted such that we only run these tests in a FIPS JVM which is the opposite of what we intend.
2019-11-14 19:44:41 -05:00
BuildParams.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(
Apply 2-space indent to all gradle scripts (#49071) Backport of #48849. Update `.editorconfig` to make the Java settings the default for all files, and then apply a 2-space indent to all `*.gradle` files. Then reformat all the files.
2019-11-14 06:01:23 -05:00
'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'
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
)