I've invested a lot of time when the TLSv1.2 became a requirement and
this
is the best solution:
- pass https.protocols to plugin configuration when a new JVM is started
(if it is not set, it'll be ignored)
- this is based on the fact that if you have a clean repo you must pass
this value anyway.
- this property must be forward compatible: if TLS1.3 is the new
default,
we should never reduce it to TLSv1.2
If the UK mirror still allows TLSv1.1, then *that* should be fixed, not
the current configuration of plugins.
thanks,
Robert
On Wed, 24 Jul 2019 23:37:31 +0200, Clemens Quoss <[email protected]>
wrote:
> Hi Robert,
> well it is already handled in the POM only for JDK 7:
>
> ...
> <profile>
> <id>jdk7</id>
> <activation>
> <jdk>(,1.7]</jdk>
> </activation>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-invoker-plugin</artifactId>
> <configuration>
> <properties combine.children="merge">
> <https.protocols>${https.protocols}</https.protocols>
> <arguments>-Dhttps.protocols=${https.protocols}</arguments>
> </properties>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </profile>
> ...
>
> Of course, this only takes care of when you release something with the
> plugin using JDK 7. When building maven-release itself you will have
to
> provide the system property for JDK 7, but not when using UK mirror
;-)
>
> Cheers, Clemens
>
> Am 24.07.2019 um 23:20 schrieb Robert Scholte:
>> Hi Clemens,
>>
>> We need to stay as close as possible to the real world.
>> With JDK8+ it should work without its being set, so the preferred way
>> it to execute it without the value being set.
>> And this way, once we must move TLS 1.3 we don't have to change all
our
>> tests.
>> Here's how we do it with our Jenkins script[1], only activate it for
>> Java 7.
>>
>> Robert
>>
>> [1]
>>
https://github.com/apache/maven-jenkins-lib/blob/master/vars/asfMavenTlpPlgnBuild.groovy#L128-L131
>>
>> On Wed, 24 Jul 2019 23:03:22 +0200, Clemens Quoss <[email protected]>
>> wrote:
>>
>>> Hi Robert,
>>> if TLSv1.2 is needed, then why not put it explicitly into the pom in
>>> line 266 [0] instead of using ${https.protocols}?
>>>
>>> Cheers, Clemens
>>>
>>> [0]
>>>
https://github.com/apache/maven-release/blob/a94c76f77ef8df1b82e9eef370412ce9b23083a0/maven-release-plugin/pom.xml#L266
>>>
>>> Am 23.07.2019 um 19:33 schrieb Robert Scholte:
>>>> Hi Clemens,
>>>>
>>>> please see
>>>>
https://central.sonatype.org/articles/2018/May/04/discontinued-support-for-tlsv11-and-below/
>>>> We'll need to contact Sonatype and verify if they included
>>>> http://uk.maven.org/maven2/ as well (they should...)
>>>>
>>>> However, AFAIK nowadays there's no need anymore to explicitly refer
>>>> to uk, it is already handled by Central CDN
>>>>
>>>> thanks,
>>>> Robert
>>>> On 23-7-2019 00:01:06, Clemens Quoss <[email protected]> wrote:
>>>> Hi Robert,
>>>> thanks for the insight. Shouldn't it fail with JDK 7 Update 80
even
>>>> with this parameter since the backport for TLSv1.2 came with Update
>>>> 95 [0]?
>>>> Since when does this requirement exist? Just checked it: I'm
using
>>>> UK
>>>> mirror [1]. This works without TLSv1.2. Maybe thats why i didn't
>>>> noticed before.
>>>> But we had problem at work contacting the Atlassian Repo from our
>>>> Nexus
>>>> that ran with JDK 7 Update 80. In that case we switched back to
JDK 6
>>>> Update 211.
>>>>
>>>> Cheers, Clemens
>>>>
>>>> [0]
>>>>
https://stackoverflow.com/questions/49523052/how-to-enable-tlsv1-2-in-java-7u80-client
>>>> [1] http://uk.maven.org/maven2/
>>>>
>>>> Am 22.07.2019 um 23:45 schrieb Robert Scholte:
>>>>> The plugin is indeed still Java 7 compatible, but that means you
must
>>>>> execute it with -Dhttps.protocols=TLSv1.2 when building it with
JDK
>>>>> 7,
>>>>> otherwise it'll fail because this is a requirement when
downloading
>>>>> from Central.
>>>>> Our CI server scripts already add this argument when running with
>>>>> Java
>>>>> 7, on your local machine it must be done by hand. This is not
>>>>> restricted to the integration tests. Try to remove your local repo
>>>>> and
>>>>> start any project running with Maven and Java 7, it'll fail very
>>>>> fast,
>>>>> i.e. by the first plugin.
>>>>>
>>>>> thanks,
>>>>> Robert
>>>>>
>>>>> On Sun, 14 Jul 2019 11:52:15 +0200, Clemens Quoss
>>>>> wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> I have provided a PR for MRELEASE-229 [1] and added some JUnit
tests
>>>>>> recently.
>>>>>>
>>>>>> Now I was wondering if i should provide an IT, too, and had a
look
>>>>>> into it:
>>>>>>
>>>>>> Running
>>>>>>
>>>>>> mvn verify -Prun-its
>>>>>>
>>>>>> with Maven 3.6.1 and JDK 7 Update 80 fails:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> [INFO] Building: projects\perform\MRELEASE-459\pom.xml
>>>>>> [INFO] run post-build script verify.groovy
>>>>>> [INFO] The post-build script did not succeed. assert
>>>>>> matcher.find()
>>>>>> | |
>>>>>> | false
>>>>>> java.util.regex.Matcher[pattern=\Q[DEBUG] Additional
>>>>>> arguments: \E(?:-Dhttps.protocols=TLSv1.2
>>>>>> )?-P(.+)\Q-DperformRelease=true -f pom.xml\E region=0,154745
>>>>>> lastmatch=]
>>>>>> [INFO] projects\perform\MRELEASE-459\pom.xml
............
>>>>>> FAILED (10.4 s)
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> IMHO it has something to do with TLSv1.2 not being backported to
JDK
>>>>>> 7 Update 80. But i may be wrong.
>>>>>>
>>>>>> With JDK 8 Update 212 the tests run successfully.
>>>>>>
>>>>>> My question is: Should the IT still run with JDK 7? I thought
so
>>>>>> since maven-release can still be build with it. If some
versions of
>>>>>> JDKs are not capable of being used for IT, shouldn't the IT run
fail
>>>>>> fast (by enforcing the eligible versions)?
>>>>>>
>>>>>> That was one question I have now redarding the ITs of
maven-release.
>>>>>> I post my other questions in separate mails.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Clemens
>>>>>>
>>>>>> [1] https://github.com/apache/maven-release/pull/29
>>>>>>
>>>>>>
>>>>>>
>>>>>>
---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
