在签名操作(BAD签名)之后，Maven会“重新部署"导致代码重新打包 [英] Maven 'deploy' cause code repackaging after the signing operation (BAD signature)

问题描述

我想将工件部署到Sonatype OSS存储库.

I want to deploy an artifact to Sonatype OSS repository.

当我使用以下命令部署时，签名无效.

When I deploy with the following command, the signatures are invalid.

mvn clean source:jar javadoc:jar install gpg:sign deploy

> gpg --verify  target/security-versions-1.0.1.jar.asc
gpg: assuming signed data in 'target/security-versions-1.0.1.jar'
gpg: Signature made 10/20/15 11:45:50 Eastern Daylight Time using RSA key ID 63E38ACF
gpg: BAD signature from "Philippe Arteau <[e-mail]>" [ultimate]

如果我删除了部署目标，则签名是良好的.

If I remove the deploy goal, the signatures are GOOD.

mvn clean source:jar javadoc:jar install gpg:sign

> gpg --verify  target/security-versions-1.0.1.jar.asc
gpg: assuming signed data in 'target/security-versions-1.0.1.jar'
gpg: Signature made 10/20/15 11:54:34 Eastern Daylight Time using RSA key ID 63E38ACF
gpg: Good signature from "Philippe Arteau <[e-mail]>" [ultimate]

我意识到在签名操作之后，罐子再次包装了. 如何在不破坏签名的情况下进行部署?

I realize that, after the sign operation, the jars were packaged a second time. How can I deploy without compromising the signatures?

问题操作:

[INFO] --- maven-gpg-plugin:1.5:sign (default-cli) @ security-versions ---

You need a passphrase to unlock the secret key for
user: "Philippe Arteau <[e-mail]>"
4096-bit RSA key, ID 63E38ACF, created 2013-05-12

[...]

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ security-versions ---
[INFO] Building jar: C:\Code\workspace-java\maven-security-versions\target\security-versions-1.0.1.jar
[INFO]
[INFO] --- maven-plugin-plugin:3.2:addPluginArtifactMetadata (default-addPluginArtifactMetadata) @ security-versions ---
[INFO]
[INFO] --- maven-source-plugin:2.2.1:jar-no-fork (default) @ security-versions ---
[INFO] Building jar: C:\Code\workspace-java\maven-security-versions\target\security-versions-1.0.1-sources.jar

由于已经进行了编译和打包，因此不应完成第二部分.

The second part should not be done since the compilation and packaging has already occurs.

推荐答案

配置

这是一种解决方法，需要在pom.xml中添加另一个XML代码段.

Configuration

Their is a workaround that need adding yet another snippet of XML in the pom.xml.

<build>
    <plugins>
        <plugin>
            <inherited>true</inherited>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-deploy-plugin</artifactId>
            <version>2.8.2</version>
            <configuration>
                <updateReleaseInfo>true</updateReleaseInfo>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>deploy</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-gpg-plugin</artifactId>
            <version>1.6</version>
            <executions>
                <execution>
                    <id>sign-artifacts</id>
                    <goals>
                        <goal>sign</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

可以在此回复中找到此示例.尽管更通用，但该人可能遇到了相同的错误.

This sample was found in this response. Although more generic, the person was probably hitting the same bug.

可以使用以下命令触发完整部署:mvn clean source:jar javadoc:jar deploy(重要:不要提及安装或验证)

The complete deployment can be trigger with : mvn clean source:jar javadoc:jar deploy (Important: Do not mention install or verify)

配置确保 gpg:sign 在 maven-deploy-plugin 之前运行.

如果提到 verify / install / sign 插件，可能会产生副作用. (mvn clean source:jar javadoc:jar verify install gpg:sign deploy) 该程序包将被递归签名多达4次(签名已签名..).

A side effect can occurs if verify/install/sign plugin is mention. (mvn clean source:jar javadoc:jar verify install gpg:sign deploy) The package will be sign up to 4 times recursively (signature being signed..).

具有 oss-parent 参考可能会触发 gpg:sign

Having the oss-parent reference might trigger gpg:sign because of this.

这篇关于在签名操作(BAD签名)之后，Maven会“重新部署"导致代码重新打包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！