You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2022/08/08 22:15:16 UTC
[VOTE] Release Apache Tomcat 8.5.82
The proposed Apache Tomcat 8.5.82 release is now available for voting.
The notable changes compared to 8.5.81 are:
- Update the packaged version of the Tomcat Native Library to 1.2.35 to
pick up Windows binaries built with OpenSSL 1.1.1q.
- Enable the use of the FIPS provider for TLS enabled Connectors when
using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
- Improvements to HTTP/2 header handling.
- Fix CVE-2022-34305, a low severity XSS vulnerability in the
Form authentication example.
Along with lots of other bug fixes and improvements.
For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1385
The tag is:
https://github.com/apache/tomcat/tree/8.5.82/
237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
The proposed 8.5.82 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.82 (stable)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 8/9/22 10:46, Mark Thomas wrote:
> On 09/08/2022 15:12, Christopher Schultz wrote:
>> All,
>>
>> I'm curious to find out if anyone is able to build a byte-for-byte
>> identical release given the 8.5.82 tag in GitHub. You won't be able to
>> generate the correct signed Windows binaries, of course, but you
>> should theoretically be able to build everything else.
>
> I'll give it a go.
>
> Note that the signed Windows binaries should build correctly. The
> detached signatures for the installer should be in the tag and the
> installer build should be reproducible. It should be possible to insert
> the detached signatures and get a valid, signed Windows binary.
I didn't build-tag-build in order to produce those detatched signatures.
>> You will need to consult build.properties.release in order to use the
>> same toolchain I used.
>>
>> Hmm. I think I ran the release-prep target before upgrading my JDK to
>> its current version. The build.properties.release file states I used
>> "Adoptium 11.0.15+10" but in fact I used "Adoptium 11.0.16+8". I'm not
>> sure if that will have a significant impact on the build in terms of
>> reproducibility.
>
> It will. The JARs that don't get processed by BND will have the Ant and
> JRE version in the manifest.
>
> Wish me luck...
:D
-chris
>> On 8/8/22 18:15, Christopher Schultz wrote:
>>> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>>>
>>> The notable changes compared to 8.5.81 are:
>>>
>>> - Update the packaged version of the Tomcat Native Library to
>>> 1.2.35 to
>>> pick up Windows binaries built with OpenSSL 1.1.1q.
>>>
>>> - Enable the use of the FIPS provider for TLS enabled Connectors when
>>> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>>>
>>> - Improvements to HTTP/2 header handling.
>>>
>>> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
>>> Form authentication example.
>>>
>>> Along with lots of other bug fixes and improvements.
>>>
>>> For full details, see the changelog:
>>> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>>>
>>> It can be obtained from:
>>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
>>> The Maven staging repo is:
>>> https://repository.apache.org/content/repositories/orgapachetomcat-1385
>>> The tag is:
>>> https://github.com/apache/tomcat/tree/8.5.82/
>>> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>>>
>>> The proposed 8.5.82 release is:
>>> [ ] Broken - do not release
>>> [ ] Stable - go ahead and release as 8.5.82 (stable)
>>>
>>> -chris
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
> 2022年8月11日 22:56，Christopher Schultz <ch...@christopherschultz.net> 写道：
>
> Han,
>
> On 8/11/22 10:31, Han Li wrote:
>>> 2022年8月11日 21:02，Konstantin Kolinko <kn...@gmail.com> 写道：
>>>
>>> чт, 11 авг. 2022 г. в 05:21, Han Li <ao...@gmail.com>:
>>>>
>>>>
>>>>
>>>>> 2022年8月11日 06:52，Konstantin Kolinko <kn...@gmail.com> 写道：
>>>>>
>>>>> ср, 10 авг. 2022 г. в 13:25, Han Li <aooohan@gmail.com <ma...@gmail.com>>:
>>>>>>
>>>>>> Mark,
>>>>>>
>>>>>> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
>>>>>> Just like this:
>>>>>> Assert.assertEquals("ok”,x);
>>>>>> The variable x becomes "好" after passing through the StringManager.
>>>>>>
>>>>>> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
>>>>>> <jvmarg value="-Duser.language=en"/>
>>>>>> <jvmarg value="-Duser.country=US"/>
>>>>>>
>>>>>> So I was wondering if we could dynamically set these two values via build.properties
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Han
>>>>>
>>>>> I think that such tests are just broken and require fixing.
>>>>>
>>>>> E.g. get an instance of StringManager and read the expected message from it.
>>>>>
>>>>>
>>>>> Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
>>>>> some Buildbot configurations, to be able to detect such tests.
>>>>
>>>> Sorry, my explanation may be confusing.
>>>>
>>>> Let me explain why with a concrete unit test. Just like this:
>>>> org.apache.catalina.valves.TestErrorReportValve#testBug53071
>>>>
>>>> ```
>>>> Assert.assertTrue(res.toString().contains("<p><b>Message</b> " +
>>>> ErrorServlet.ERROR_TEXT + "</p>"));
>>>> ```
>>>> org.apache.catalina.valves.ErrorReportValve#report
>>>> ```
>>>> sb.append("<p><b>");
>>>> sb.append(smClient.getString("errorReportValve.message"));
>>>> sb.append("</b> ");
>>>> ```
>>>> Since the local of my OS is zh-CN, the response contains `<p><b>信息</b> .... ` instead of `<p><b>Message</b>.... ', so I’m trying to avoid this by changing user.language and user.country.
>>>> Unfortunately, I can’t find any way to do this at the moment, so I have to manually modify the build.xml.
>>>>
>>>
>>> 1. I think that you could add a request header
>>>
>>> Accept-Language: en-US
>>>
>>> using the variant of getUrl() call that accepts a "reqHead" map.
>>>
>>> In TomcatBaseTest:
>>> public static int getUrl(String path, ByteChunk out, Map<String,
>>> List<String>> reqHead,
>>> Map<String, List<String>> resHead) throws IOException {
>>>
>> I’ve tried to do this and `en_US` does not work properly, `en` does. For reasons I think I already know.
<!-- SNIP -->
>
> Did you try en-US? These are RFC 1766 language tags which use hyphens and not underscores. https://www.rfc-editor.org/rfc/rfc1766 <https://www.rfc-editor.org/rfc/rfc1766>
>
Yes, I'm using en-US, when you asked me I thought I was using en_US, now I'm sure it's en-US, it's not working properly.
Han
>> I will propose a BZ to describe this failure test and a PR to fix it.
>
> Excellent.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Han,
On 8/11/22 10:31, Han Li wrote:
>
>
>> 2022年8月11日 21:02，Konstantin Kolinko <kn...@gmail.com> 写道：
>>
>> чт, 11 авг. 2022 г. в 05:21, Han Li <ao...@gmail.com>:
>>>
>>>
>>>
>>>> 2022年8月11日 06:52，Konstantin Kolinko <kn...@gmail.com> 写道：
>>>>
>>>> ср, 10 авг. 2022 г. в 13:25, Han Li <aooohan@gmail.com <ma...@gmail.com>>:
>>>>>
>>>>> Mark,
>>>>>
>>>>> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
>>>>> Just like this:
>>>>> Assert.assertEquals("ok”,x);
>>>>> The variable x becomes "好" after passing through the StringManager.
>>>>>
>>>>> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
>>>>> <jvmarg value="-Duser.language=en"/>
>>>>> <jvmarg value="-Duser.country=US"/>
>>>>>
>>>>> So I was wondering if we could dynamically set these two values via build.properties
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Han
>>>>
>>>> I think that such tests are just broken and require fixing.
>>>>
>>>> E.g. get an instance of StringManager and read the expected message from it.
>>>>
>>>>
>>>> Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
>>>> some Buildbot configurations, to be able to detect such tests.
>>>
>>> Sorry, my explanation may be confusing.
>>>
>>> Let me explain why with a concrete unit test. Just like this:
>>> org.apache.catalina.valves.TestErrorReportValve#testBug53071
>>>
>>> ```
>>> Assert.assertTrue(res.toString().contains("<p><b>Message</b> " +
>>> ErrorServlet.ERROR_TEXT + "</p>"));
>>> ```
>>> org.apache.catalina.valves.ErrorReportValve#report
>>> ```
>>> sb.append("<p><b>");
>>> sb.append(smClient.getString("errorReportValve.message"));
>>> sb.append("</b> ");
>>> ```
>>> Since the local of my OS is zh-CN, the response contains `<p><b>信息</b> .... ` instead of `<p><b>Message</b>.... ', so I’m trying to avoid this by changing user.language and user.country.
>>> Unfortunately, I can’t find any way to do this at the moment, so I have to manually modify the build.xml.
>>>
>>
>
>
>
>> 1. I think that you could add a request header
>>
>> Accept-Language: en-US
>>
>> using the variant of getUrl() call that accepts a "reqHead" map.
>>
>> In TomcatBaseTest:
>> public static int getUrl(String path, ByteChunk out, Map<String,
>> List<String>> reqHead,
>> Map<String, List<String>> resHead) throws IOException {
>>
>
> I’ve tried to do this and `en_US` does not work properly, `en` does. For reasons I think I already know.
Did you try en-US? These are RFC 1766 language tags which use hyphens
and not underscores. https://www.rfc-editor.org/rfc/rfc1766
> I will propose a BZ to describe this failure test and a PR to fix it.
Excellent.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
> 2022年8月11日 21:02，Konstantin Kolinko <kn...@gmail.com> 写道：
>
> чт, 11 авг. 2022 г. в 05:21, Han Li <ao...@gmail.com>:
>>
>>
>>
>>> 2022年8月11日 06:52，Konstantin Kolinko <kn...@gmail.com> 写道：
>>>
>>> ср, 10 авг. 2022 г. в 13:25, Han Li <aooohan@gmail.com <ma...@gmail.com>>:
>>>>
>>>> Mark,
>>>>
>>>> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
>>>> Just like this:
>>>> Assert.assertEquals("ok”,x);
>>>> The variable x becomes "好" after passing through the StringManager.
>>>>
>>>> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
>>>> <jvmarg value="-Duser.language=en"/>
>>>> <jvmarg value="-Duser.country=US"/>
>>>>
>>>> So I was wondering if we could dynamically set these two values via build.properties
>>>>
>>>> Thanks,
>>>>
>>>> Han
>>>
>>> I think that such tests are just broken and require fixing.
>>>
>>> E.g. get an instance of StringManager and read the expected message from it.
>>>
>>>
>>> Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
>>> some Buildbot configurations, to be able to detect such tests.
>>
>> Sorry, my explanation may be confusing.
>>
>> Let me explain why with a concrete unit test. Just like this:
>> org.apache.catalina.valves.TestErrorReportValve#testBug53071
>>
>> ```
>> Assert.assertTrue(res.toString().contains("<p><b>Message</b> " +
>> ErrorServlet.ERROR_TEXT + "</p>"));
>> ```
>> org.apache.catalina.valves.ErrorReportValve#report
>> ```
>> sb.append("<p><b>");
>> sb.append(smClient.getString("errorReportValve.message"));
>> sb.append("</b> ");
>> ```
>> Since the local of my OS is zh-CN, the response contains `<p><b>信息</b> .... ` instead of `<p><b>Message</b>.... ', so I’m trying to avoid this by changing user.language and user.country.
>> Unfortunately, I can’t find any way to do this at the moment, so I have to manually modify the build.xml.
>>
>
> 1. I think that you could add a request header
>
> Accept-Language: en-US
>
> using the variant of getUrl() call that accepts a "reqHead" map.
>
> In TomcatBaseTest:
> public static int getUrl(String path, ByteChunk out, Map<String,
> List<String>> reqHead,
> Map<String, List<String>> resHead) throws IOException {
>
I’ve tried to do this and `en_US` does not work properly, `en` does. For reasons I think I already know.
I will propose a BZ to describe this failure test and a PR to fix it.
> 2. Alternatively, using StringManager:
>
> StringManager smClient = StringManager.getManager(
> Constants.Package, request.getLocales());
>
> where Constants is org.apache.catalina.valves.Constants
>
> ServletRequest.getLocales() is documented as:
> * header. If the client request doesn't provide an Accept-Language header,
> * this method returns an <code>Enumeration</code> containing one
> * <code>Locale</code>, the default locale for the server.
Surprisingly, based on your suggestion, I found another bug suspected to belong to StringManager.
I will propose another BZ to describe it.
>
>
>
> 3. BTW, I was faxing a similar failure3 years ago,
> https://github.com/apache/tomcat/commit/1758f6460a8e8fbf38b88385860379a4424cc66b
>
> Time flies fast...
Thank you for all the work you do！
Thanks,
Han
>
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Konstantin Kolinko <kn...@gmail.com>.
чт, 11 авг. 2022 г. в 05:21, Han Li <ao...@gmail.com>:
>
>
>
> > 2022年8月11日 06:52，Konstantin Kolinko <kn...@gmail.com> 写道：
> >
> > ср, 10 авг. 2022 г. в 13:25, Han Li <aooohan@gmail.com <ma...@gmail.com>>:
> >>
> >> Mark,
> >>
> >> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
> >> Just like this:
> >> Assert.assertEquals("ok”,x);
> >> The variable x becomes "好" after passing through the StringManager.
> >>
> >> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
> >> <jvmarg value="-Duser.language=en"/>
> >> <jvmarg value="-Duser.country=US"/>
> >>
> >> So I was wondering if we could dynamically set these two values via build.properties
> >>
> >> Thanks,
> >>
> >> Han
> >
> > I think that such tests are just broken and require fixing.
> >
> > E.g. get an instance of StringManager and read the expected message from it.
> >
> >
> > Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
> > some Buildbot configurations, to be able to detect such tests.
>
> Sorry, my explanation may be confusing.
>
> Let me explain why with a concrete unit test. Just like this:
> org.apache.catalina.valves.TestErrorReportValve#testBug53071
>
> ```
> Assert.assertTrue(res.toString().contains("<p><b>Message</b> " +
> ErrorServlet.ERROR_TEXT + "</p>"));
> ```
> org.apache.catalina.valves.ErrorReportValve#report
> ```
> sb.append("<p><b>");
> sb.append(smClient.getString("errorReportValve.message"));
> sb.append("</b> ");
> ```
> Since the local of my OS is zh-CN, the response contains `<p><b>信息</b> .... ` instead of `<p><b>Message</b>.... ', so I’m trying to avoid this by changing user.language and user.country.
> Unfortunately, I can’t find any way to do this at the moment, so I have to manually modify the build.xml.
>
1. I think that you could add a request header
Accept-Language: en-US
using the variant of getUrl() call that accepts a "reqHead" map.
In TomcatBaseTest:
public static int getUrl(String path, ByteChunk out, Map<String,
List<String>> reqHead,
Map<String, List<String>> resHead) throws IOException {
2. Alternatively, using StringManager:
StringManager smClient = StringManager.getManager(
Constants.Package, request.getLocales());
where Constants is org.apache.catalina.valves.Constants
ServletRequest.getLocales() is documented as:
* header. If the client request doesn't provide an Accept-Language header,
* this method returns an <code>Enumeration</code> containing one
* <code>Locale</code>, the default locale for the server.
3. BTW, I was faxing a similar failure3 years ago,
https://github.com/apache/tomcat/commit/1758f6460a8e8fbf38b88385860379a4424cc66b
Time flies fast...
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
> 2022年8月11日 06:52，Konstantin Kolinko <kn...@gmail.com> 写道：
>
> ср, 10 авг. 2022 г. в 13:25, Han Li <aooohan@gmail.com <ma...@gmail.com>>:
>>
>> Mark,
>>
>> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
>> Just like this:
>> Assert.assertEquals("ok”,x);
>> The variable x becomes "好" after passing through the StringManager.
>>
>> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
>> <jvmarg value="-Duser.language=en"/>
>> <jvmarg value="-Duser.country=US"/>
>>
>> So I was wondering if we could dynamically set these two values via build.properties
>>
>> Thanks,
>>
>> Han
>
> I think that such tests are just broken and require fixing.
>
> E.g. get an instance of StringManager and read the expected message from it.
>
>
> Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
> some Buildbot configurations, to be able to detect such tests.
Sorry, my explanation may be confusing.
Let me explain why with a concrete unit test. Just like this:
org.apache.catalina.valves.TestErrorReportValve#testBug53071
```
Assert.assertTrue(res.toString().contains("<p><b>Message</b> " +
ErrorServlet.ERROR_TEXT + "</p>"));
```
org.apache.catalina.valves.ErrorReportValve#report
```
sb.append("<p><b>");
sb.append(smClient.getString("errorReportValve.message"));
sb.append("</b> ");
```
Since the local of my OS is zh-CN, the response contains `<p><b>信息</b> .... ` instead of `<p><b>Message</b>.... ', so I’m trying to avoid this by changing user.language and user.country.
Unfortunately, I can’t find any way to do this at the moment, so I have to manually modify the build.xml.
Thanks,
Han
>
> (Though
> - It would be hard to read their logs, if anything happens. As the
> logs will be in Chinese.
>
> - Such an approach assumes that there is something to detect. A
> broken test is only broken for languages where translation exists and
> differs from the default.)
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Konstantin Kolinko <kn...@gmail.com>.
ср, 10 авг. 2022 г. в 13:25, Han Li <ao...@gmail.com>:
>
> Mark,
>
> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
> Just like this:
> Assert.assertEquals("ok”,x);
> The variable x becomes "好" after passing through the StringManager.
>
> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
> <jvmarg value="-Duser.language=en"/>
> <jvmarg value="-Duser.country=US"/>
>
> So I was wondering if we could dynamically set these two values via build.properties
>
> Thanks,
>
> Han
I think that such tests are just broken and require fixing.
E.g. get an instance of StringManager and read the expected message from it.
Maybe we can add -Duser.language=zh -Duser.country=CN to ANT_OPTS in
some Buildbot configurations, to be able to detect such tests.
(Though
- It would be hard to read their logs, if anything happens. As the
logs will be in Chinese.
- Such an approach assumes that there is something to detect. A
broken test is only broken for languages where translation exists and
differs from the default.)
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
> 2022年8月11日 05:20，Christopher Schultz <ch...@christopherschultz.net> 写道：
>
> Han,
>
> On 8/10/22 06:25, Han Li wrote:
>> Mark,
>> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
>> Just like this:
>> Assert.assertEquals("ok”,x);
>> The variable x becomes "好" after passing through the StringManager.
>> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
>> <jvmarg value="-Duser.language=en"/>
>> <jvmarg value="-Duser.country=US"/>
>> So I was wondering if we could dynamically set these two values via build.properties
>
> So, two things:
>
> 1. You are proposing that we "copy" user.language and user.country from the ant JVM into the forked-ant JVM that runs the tests?
Yes!
>
> I'm perfectly happy to add that permanently. I see no reason not to do that.
In addition, I think that we can set user.country and user.language in build.properties, not necessary to set them in ANT_OPTS.
>
> 2. If you set user.language and user.country in either ~/build.properties or ... just have them auto-set by your environment (e.g. your OS is set to use a particular locale) that should work. Are these values not *already* copied from ant JVM into forked-ant JVM for testing?
Not copied into forked-ant JVM.
Thanks,
Han
>
> -chris
>
>>> 2022年8月10日 18:02，Mark Thomas <ma...@apache.org> 写道：
>>>
>>> On 09/08/2022 20:19, Christopher Schultz wrote:
>>>> On 8/9/22 14:09, Mark Thomas wrote:
>>>
>>> <snip/>
>>>
>>>>> This issue is the zip files. Time stamps in zip files use local (yes, local - I didn't mistype that) time. Hence you need to use the same time zone to get a repeatable build.
>>>>>
>>>>> We have a few options here:
>>>>>
>>>>> 1. Document the time zone in use for the build and require the same timezone to be used for repeatable builds.
>>>> We might want to do this anyway, regardless.
>>>
>>> Agreed. I also spotted that adding "do.codesigning=true" would help repeatable builds. I'll get both of those added.
>>>
>>>>> 2. Require UTC.
>>>> Can that be done on the CLI for a single process on Windows? It will likely work for *NIX no problem. I use a semi-dedicated Windows VM for building releases, so I have no problem just switching it to UTC.
>>>
>>> I'm not sure. Figuring that out is next on my TODO list. I'd really like to make this part of the Ant build script if I can though.
>>>
>>>> I also really need to switch to building natively on my Mac because the whole VM thing is really cramping my style. :)
>>>
>>> That should be doable. From memory, wine required a little hoop jumping to get working but it didn't take too long.
>>>
>>>>> 3. Find a way to force Ant to use a specific timezone.
>>>> -Duser.timezone?
>>>
>>> That should work. We could require that to be used on the command line. I was hoping to find a way to set that within the script so the release manager still just has to do a "ant release".
>>>
>>> I was thinking about a custom Ant task that set the global time zone (if there isn't anything built into Any that does that).
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org <ma...@tomcat.apache.org>
>> For additional commands, e-mail: dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Han,
On 8/10/22 06:25, Han Li wrote:
> Mark,
>
> Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
> Just like this:
> Assert.assertEquals("ok”,x);
> The variable x becomes "好" after passing through the StringManager.
>
> So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
> <jvmarg value="-Duser.language=en"/>
> <jvmarg value="-Duser.country=US"/>
>
> So I was wondering if we could dynamically set these two values via build.properties
So, two things:
1. You are proposing that we "copy" user.language and user.country from
the ant JVM into the forked-ant JVM that runs the tests?
I'm perfectly happy to add that permanently. I see no reason not to do that.
2. If you set user.language and user.country in either
~/build.properties or ... just have them auto-set by your environment
(e.g. your OS is set to use a particular locale) that should work. Are
these values not *already* copied from ant JVM into forked-ant JVM for
testing?
-chris
>> 2022年8月10日 18:02，Mark Thomas <ma...@apache.org> 写道：
>>
>> On 09/08/2022 20:19, Christopher Schultz wrote:
>>> On 8/9/22 14:09, Mark Thomas wrote:
>>
>> <snip/>
>>
>>>> This issue is the zip files. Time stamps in zip files use local (yes, local - I didn't mistype that) time. Hence you need to use the same time zone to get a repeatable build.
>>>>
>>>> We have a few options here:
>>>>
>>>> 1. Document the time zone in use for the build and require the same timezone to be used for repeatable builds.
>>> We might want to do this anyway, regardless.
>>
>> Agreed. I also spotted that adding "do.codesigning=true" would help repeatable builds. I'll get both of those added.
>>
>>>> 2. Require UTC.
>>> Can that be done on the CLI for a single process on Windows? It will likely work for *NIX no problem. I use a semi-dedicated Windows VM for building releases, so I have no problem just switching it to UTC.
>>
>> I'm not sure. Figuring that out is next on my TODO list. I'd really like to make this part of the Ant build script if I can though.
>>
>>> I also really need to switch to building natively on my Mac because the whole VM thing is really cramping my style. :)
>>
>> That should be doable. From memory, wine required a little hoop jumping to get working but it didn't take too long.
>>
>>>> 3. Find a way to force Ant to use a specific timezone.
>>> -Duser.timezone?
>>
>> That should work. We could require that to be used on the command line. I was hoping to find a way to set that within the script so the release manager still just has to do a "ant release".
>>
>> I was thinking about a custom Ant task that set the global time zone (if there isn't anything built into Any that does that).
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
Mark,
Can I make a suggestion related to the ant build script. Can we add two properties to set the values of ` -Duser.language` and `-Duser.country`, because in the course of my testing I found that some of the unit test assertions are in English, but there may be cases where the values are converted by sm, e.g. Chinese.
Just like this:
Assert.assertEquals("ok”,x);
The variable x becomes "好" after passing through the StringManager.
So this makes it a bit inconvenient for non-English speaking developers to test. I avoid this problem by adding a statement to build.xml each time I run a test.
<jvmarg value="-Duser.language=en"/>
<jvmarg value="-Duser.country=US"/>
So I was wondering if we could dynamically set these two values via build.properties
Thanks,
Han
> 2022年8月10日 18:02，Mark Thomas <ma...@apache.org> 写道：
>
> On 09/08/2022 20:19, Christopher Schultz wrote:
>> On 8/9/22 14:09, Mark Thomas wrote:
>
> <snip/>
>
>>> This issue is the zip files. Time stamps in zip files use local (yes, local - I didn't mistype that) time. Hence you need to use the same time zone to get a repeatable build.
>>>
>>> We have a few options here:
>>>
>>> 1. Document the time zone in use for the build and require the same timezone to be used for repeatable builds.
>> We might want to do this anyway, regardless.
>
> Agreed. I also spotted that adding "do.codesigning=true" would help repeatable builds. I'll get both of those added.
>
>>> 2. Require UTC.
>> Can that be done on the CLI for a single process on Windows? It will likely work for *NIX no problem. I use a semi-dedicated Windows VM for building releases, so I have no problem just switching it to UTC.
>
> I'm not sure. Figuring that out is next on my TODO list. I'd really like to make this part of the Ant build script if I can though.
>
>> I also really need to switch to building natively on my Mac because the whole VM thing is really cramping my style. :)
>
> That should be doable. From memory, wine required a little hoop jumping to get working but it didn't take too long.
>
>>> 3. Find a way to force Ant to use a specific timezone.
>> -Duser.timezone?
>
> That should work. We could require that to be used on the command line. I was hoping to find a way to set that within the script so the release manager still just has to do a "ant release".
>
> I was thinking about a custom Ant task that set the global time zone (if there isn't anything built into Any that does that).
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Mark Thomas <ma...@apache.org>.
On 10/08/2022 22:16, Christopher Schultz wrote:
> On 8/10/22 06:02, Mark Thomas wrote:
>> Agreed. I also spotted that adding "do.codesigning=true" would help
>> repeatable builds. I'll get both of those added.
>
> I don't think we want that to affect people trying to perform their own
> builds. It will fail every time, right? I have do.codesigning=true in
> ~/build.properties which should be sufficient for Tomcat release managers.
It shouldn't fail. I was thinking of adding "do.codesigning=true" in
build.properties.release. The builds are repeatable (assuming the
timezone issue is fixed) so inserting the detached signature should work.
>>>> 2. Require UTC.
>>>
>>> Can that be done on the CLI for a single process on Windows? It will
>>> likely work for *NIX no problem. I use a semi-dedicated Windows VM
>>> for building releases, so I have no problem just switching it to UTC.
>>
>> I'm not sure. Figuring that out is next on my TODO list. I'd really
>> like to make this part of the Ant build script if I can though.
>
> +1
>
>>> I also really need to switch to building natively on my Mac because
>>> the whole VM thing is really cramping my style. :)
>>
>> That should be doable. From memory, wine required a little hoop
>> jumping to get working but it didn't take too long.
>
> It's the wine thing that's really stopping me. Ironically, I already
> have Crossover (which is paid-for wine) installed and it would be nice
> it I could just use that, but my guess is it would be enough of a PITA
> to get working that I should just install Vanilla wine and use that.
You might be surprised. The hassle (for me) was getting the initial
configuration right to run wine in 64-bit mode on MacOS. The build "just
worked". I was pleasantly surprised when I was working on repeatable
builds that used wine on Linux to find that the NSIS output was
identical with no configuration tweaks required.
>>>> 3. Find a way to force Ant to use a specific timezone.
>>>
>>> -Duser.timezone?
>>
>> That should work. We could require that to be used on the command
>> line. I was hoping to find a way to set that within the script so the
>> release manager still just has to do a "ant release".
>
> Put it in pre-release, and stash it into build.properties.release?
Agreed. I'm trying to figure out exactly what to put in there.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 8/10/22 06:02, Mark Thomas wrote:
> On 09/08/2022 20:19, Christopher Schultz wrote:
>> On 8/9/22 14:09, Mark Thomas wrote:
>
> <snip/>
>
>>> This issue is the zip files. Time stamps in zip files use local (yes,
>>> local - I didn't mistype that) time. Hence you need to use the same
>>> time zone to get a repeatable build.
>>>
>>> We have a few options here:
>>>
>>> 1. Document the time zone in use for the build and require the same
>>> timezone to be used for repeatable builds.
>>
>> We might want to do this anyway, regardless.
>
> Agreed. I also spotted that adding "do.codesigning=true" would help
> repeatable builds. I'll get both of those added.
I don't think we want that to affect people trying to perform their own
builds. It will fail every time, right? I have do.codesigning=true in
~/build.properties which should be sufficient for Tomcat release managers.
>>> 2. Require UTC.
>>
>> Can that be done on the CLI for a single process on Windows? It will
>> likely work for *NIX no problem. I use a semi-dedicated Windows VM for
>> building releases, so I have no problem just switching it to UTC.
>
> I'm not sure. Figuring that out is next on my TODO list. I'd really like
> to make this part of the Ant build script if I can though.
+1
>> I also really need to switch to building natively on my Mac because
>> the whole VM thing is really cramping my style. :)
>
> That should be doable. From memory, wine required a little hoop jumping
> to get working but it didn't take too long.
It's the wine thing that's really stopping me. Ironically, I already
have Crossover (which is paid-for wine) installed and it would be nice
it I could just use that, but my guess is it would be enough of a PITA
to get working that I should just install Vanilla wine and use that.
>>> 3. Find a way to force Ant to use a specific timezone.
>>
>> -Duser.timezone?
>
> That should work. We could require that to be used on the command line.
> I was hoping to find a way to set that within the script so the release
> manager still just has to do a "ant release".
Put it in pre-release, and stash it into build.properties.release?
> I was thinking about a custom Ant task that set the global time zone (if
> there isn't anything built into Any that does that).
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Mark Thomas <ma...@apache.org>.
On 09/08/2022 20:19, Christopher Schultz wrote:
> On 8/9/22 14:09, Mark Thomas wrote:
<snip/>
>> This issue is the zip files. Time stamps in zip files use local (yes,
>> local - I didn't mistype that) time. Hence you need to use the same
>> time zone to get a repeatable build.
>>
>> We have a few options here:
>>
>> 1. Document the time zone in use for the build and require the same
>> timezone to be used for repeatable builds.
>
> We might want to do this anyway, regardless.
Agreed. I also spotted that adding "do.codesigning=true" would help
repeatable builds. I'll get both of those added.
>> 2. Require UTC.
>
> Can that be done on the CLI for a single process on Windows? It will
> likely work for *NIX no problem. I use a semi-dedicated Windows VM for
> building releases, so I have no problem just switching it to UTC.
I'm not sure. Figuring that out is next on my TODO list. I'd really like
to make this part of the Ant build script if I can though.
> I also really need to switch to building natively on my Mac because the
> whole VM thing is really cramping my style. :)
That should be doable. From memory, wine required a little hoop jumping
to get working but it didn't take too long.
>> 3. Find a way to force Ant to use a specific timezone.
>
> -Duser.timezone?
That should work. We could require that to be used on the command line.
I was hoping to find a way to set that within the script so the release
manager still just has to do a "ant release".
I was thinking about a custom Ant task that set the global time zone (if
there isn't anything built into Any that does that).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 8/9/22 14:09, Mark Thomas wrote:
> On 09/08/2022 16:22, Mark Thomas wrote:
>> On 09/08/2022 15:46, Mark Thomas wrote:
>>> On 09/08/2022 15:12, Christopher Schultz wrote:
>>>> All,
>>>>
>>>> I'm curious to find out if anyone is able to build a byte-for-byte
>>>> identical release given the 8.5.82 tag in GitHub. You won't be able
>>>> to generate the correct signed Windows binaries, of course, but you
>>>> should theoretically be able to build everything else.
>>
>> TL;DR the build isn't reproducible.
>>
>> There is something weird going on with time zones and timestamps that
>> I haven't got my head around yet. The tar.gz source archive is fine.
>> The zip archive is not.
>>
>> In the release vote files, the files in the zip archive have a
>> timestamp 15 hours earlier that those in the tar.gz archive. In my
>> local build the files in the zip archive have a timestamp 1 hour later
>> than the tar.gz archive.
>>
>> I'm digging into this now.
>
> Good news and bad news.
>
> Once I switched my machine to the same timezone Chris was in when he
> built the release, the release was 100% repeatable.
>
> This issue is the zip files. Time stamps in zip files use local (yes,
> local - I didn't mistype that) time. Hence you need to use the same time
> zone to get a repeatable build.
>
> We have a few options here:
>
> 1. Document the time zone in use for the build and require the same
> timezone to be used for repeatable builds.
We might want to do this anyway, regardless.
> 2. Require UTC.
Can that be done on the CLI for a single process on Windows? It will
likely work for *NIX no problem. I use a semi-dedicated Windows VM for
building releases, so I have no problem just switching it to UTC.
I also really need to switch to building natively on my Mac because the
whole VM thing is really cramping my style. :)
> 3. Find a way to force Ant to use a specific timezone.
-Duser.timezone?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Mark Thomas <ma...@apache.org>.
On 09/08/2022 16:22, Mark Thomas wrote:
> On 09/08/2022 15:46, Mark Thomas wrote:
>> On 09/08/2022 15:12, Christopher Schultz wrote:
>>> All,
>>>
>>> I'm curious to find out if anyone is able to build a byte-for-byte
>>> identical release given the 8.5.82 tag in GitHub. You won't be able
>>> to generate the correct signed Windows binaries, of course, but you
>>> should theoretically be able to build everything else.
>
> TL;DR the build isn't reproducible.
>
> There is something weird going on with time zones and timestamps that I
> haven't got my head around yet. The tar.gz source archive is fine. The
> zip archive is not.
>
> In the release vote files, the files in the zip archive have a timestamp
> 15 hours earlier that those in the tar.gz archive. In my local build the
> files in the zip archive have a timestamp 1 hour later than the tar.gz
> archive.
>
> I'm digging into this now.
Good news and bad news.
Once I switched my machine to the same timezone Chris was in when he
built the release, the release was 100% repeatable.
This issue is the zip files. Time stamps in zip files use local (yes,
local - I didn't mistype that) time. Hence you need to use the same time
zone to get a repeatable build.
We have a few options here:
1. Document the time zone in use for the build and require the same
timezone to be used for repeatable builds.
2. Require UTC.
3. Find a way to force Ant to use a specific timezone.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Mark Thomas <ma...@apache.org>.
On 09/08/2022 15:46, Mark Thomas wrote:
> On 09/08/2022 15:12, Christopher Schultz wrote:
>> All,
>>
>> I'm curious to find out if anyone is able to build a byte-for-byte
>> identical release given the 8.5.82 tag in GitHub. You won't be able to
>> generate the correct signed Windows binaries, of course, but you
>> should theoretically be able to build everything else.
TL;DR the build isn't reproducible.
There is something weird going on with time zones and timestamps that I
haven't got my head around yet. The tar.gz source archive is fine. The
zip archive is not.
In the release vote files, the files in the zip archive have a timestamp
15 hours earlier that those in the tar.gz archive. In my local build the
files in the zip archive have a timestamp 1 hour later than the tar.gz
archive.
I'm digging into this now.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Mark Thomas <ma...@apache.org>.
On 09/08/2022 15:12, Christopher Schultz wrote:
> All,
>
> I'm curious to find out if anyone is able to build a byte-for-byte
> identical release given the 8.5.82 tag in GitHub. You won't be able to
> generate the correct signed Windows binaries, of course, but you should
> theoretically be able to build everything else.
I'll give it a go.
Note that the signed Windows binaries should build correctly. The
detached signatures for the installer should be in the tag and the
installer build should be reproducible. It should be possible to insert
the detached signatures and get a valid, signed Windows binary.
> You will need to consult build.properties.release in order to use the
> same toolchain I used.
>
> Hmm. I think I ran the release-prep target before upgrading my JDK to
> its current version. The build.properties.release file states I used
> "Adoptium 11.0.15+10" but in fact I used "Adoptium 11.0.16+8". I'm not
> sure if that will have a significant impact on the build in terms of
> reproducibility.
It will. The JARs that don't get processed by BND will have the Ant and
JRE version in the manifest.
Wish me luck...
Mark
>
> Thanks,
> -chris
>
> On 8/8/22 18:15, Christopher Schultz wrote:
>> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>>
>> The notable changes compared to 8.5.81 are:
>>
>> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
>> pick up Windows binaries built with OpenSSL 1.1.1q.
>>
>> - Enable the use of the FIPS provider for TLS enabled Connectors when
>> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>>
>> - Improvements to HTTP/2 header handling.
>>
>> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
>> Form authentication example.
>>
>> Along with lots of other bug fixes and improvements.
>>
>> For full details, see the changelog:
>> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>>
>> It can be obtained from:
>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
>> The Maven staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomcat-1385
>> The tag is:
>> https://github.com/apache/tomcat/tree/8.5.82/
>> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>>
>> The proposed 8.5.82 release is:
>> [ ] Broken - do not release
>> [ ] Stable - go ahead and release as 8.5.82 (stable)
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
I'm curious to find out if anyone is able to build a byte-for-byte
identical release given the 8.5.82 tag in GitHub. You won't be able to
generate the correct signed Windows binaries, of course, but you should
theoretically be able to build everything else.
You will need to consult build.properties.release in order to use the
same toolchain I used.
Hmm. I think I ran the release-prep target before upgrading my JDK to
its current version. The build.properties.release file states I used
"Adoptium 11.0.15+10" but in fact I used "Adoptium 11.0.16+8". I'm not
sure if that will have a significant impact on the build in terms of
reproducibility.
Thanks,
-chris
On 8/8/22 18:15, Christopher Schultz wrote:
> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>
> The notable changes compared to 8.5.81 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
> pick up Windows binaries built with OpenSSL 1.1.1q.
>
> - Enable the use of the FIPS provider for TLS enabled Connectors when
> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>
> - Improvements to HTTP/2 header handling.
>
> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
> Form authentication example.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1385
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.82/
> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>
> The proposed 8.5.82 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 8.5.82 (stable)
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
> 2022年8月9日 06:15，Christopher Schultz <ch...@christopherschultz.net> 写道：
>
> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>
> The notable changes compared to 8.5.81 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
> pick up Windows binaries built with OpenSSL 1.1.1q.
>
> - Enable the use of the FIPS provider for TLS enabled Connectors when
> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>
> - Improvements to HTTP/2 header handling.
>
> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
> Form authentication example.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1385
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.82/
> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>
> The proposed 8.5.82 release is:
> [ ] Broken - do not release
> [x ] Stable - go ahead and release as 8.5.82 (stable)
All unit tests pass with Tomcat Native 1.2.35 built with OpenSSL 3.0.5 on MacOS 12.3.1.
Han.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 8/8/22 18:15, Christopher Schultz wrote:
> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>
> The notable changes compared to 8.5.81 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
> pick up Windows binaries built with OpenSSL 1.1.1q.
>
> - Enable the use of the FIPS provider for TLS enabled Connectors when
> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>
> - Improvements to HTTP/2 header handling.
>
> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
> Form authentication example.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1385
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.82/
> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>
> The proposed 8.5.82 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.82 (stable)
Works with a vanilla application in a development environment.
Notes on the "details" below:
1. The "Signature verification failed" for the Windows binary is due to
a misconfiguration of osslsigncode on the server I used to run my tests.
I have corrected that and verified that the Windows binary is
properly-signed.
2. The failures for the PEMFile tests are due to a bug in the JVM which
has been fixed in Java 1.8.0-8u301 while the version used for testing
here is 1.8.0-8u292.
Details:
* Environment
* Java (build): openjdk version "1.8.0_292" OpenJDK Runtime
Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10) OpenJDK 64-Bit
Server VM (build 25.292-b10, mixed mode)
* Java (test): openjdk version "1.8.0_292" OpenJDK Runtime
Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10) OpenJDK 64-Bit
Server VM (build 25.292-b10, mixed mode)
* OS: Linux 5.10.0-14-amd64 x86_64
* cc: cc (Debian 10.2.1-6) 10.2.1 20210110
* make: GNU Make 4.3
* OpenSSL: OpenSSL 1.1.1 11 Sep 2018
* APR: 1.7.0
*
* Valid SHA-512 signature for apache-tomcat-8.5.82.zip
* Valid GPG signature for apache-tomcat-8.5.82.zip
* Valid SHA-512 signature for apache-tomcat-8.5.82.tar.gz
* Valid GPG signature for apache-tomcat-8.5.82.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.82.exe
* Valid GPG signature for apache-tomcat-8.5.82.exe
* !! Invalid Windows Digital Signature for apache-tomcat-8.5.82.exe
* Valid SHA512 signature for apache-tomcat-8.5.82-src.zip
* Valid GPG signature for apache-tomcat-8.5.82-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.82-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.82-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.tomcat.util.net.jsse.TestPEMFile.APR.txt
* org.apache.tomcat.util.net.jsse.TestPEMFile.NIO.txt
* org.apache.tomcat.util.net.jsse.TestPEMFile.NIO2.txt
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Filip Hanik <fi...@hanik.com>.
On Mon, Aug 8, 2022 at 3:15 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>
> The notable changes compared to 8.5.81 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
> pick up Windows binaries built with OpenSSL 1.1.1q.
>
> - Enable the use of the FIPS provider for TLS enabled Connectors when
> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>
> - Improvements to HTTP/2 header handling.
>
> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
> Form authentication example.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1385
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.82/
> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>
> The proposed 8.5.82 release is:
> [ ] Broken - do not release
>
> [X] Stable - go ahead and release as 8.5.82 (stable)
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
Thanks for your reply.
Han
> 2022年8月10日 02:36，Christopher Schultz <ch...@christopherschultz.net> 写道：
>
> Han,
>
> On 8/9/22 10:46, Han Li wrote:
>>> 2022年8月9日 22:25，Rémy Maucherat <re...@apache.org> 写道：
>>>
>>> On Tue, Aug 9, 2022 at 12:16 AM Christopher Schultz
>>> <chris@christopherschultz.net <ma...@christopherschultz.net>> wrote:
>>>>
>>>> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>>>>
>>>> The notable changes compared to 8.5.81 are:
>>>>
>>>> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
>>>> pick up Windows binaries built with OpenSSL 1.1.1q.
>>>>
>>>> - Enable the use of the FIPS provider for TLS enabled Connectors when
>>>> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>>>>
>>>> - Improvements to HTTP/2 header handling.
>>>>
>>>> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
>>>> Form authentication example.
>>>>
>>>> Along with lots of other bug fixes and improvements.
>>>>
>>>> For full details, see the changelog:
>>>> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>>>>
>>>> It can be obtained from:
>>>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
>>>> The Maven staging repo is:
>>>> https://repository.apache.org/content/repositories/orgapachetomcat-1385
>>>> The tag is:
>>>> https://github.com/apache/tomcat/tree/8.5.82/
>>>> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>>>>
>>>> The proposed 8.5.82 release is:
>>>> [ ] Broken - do not release
>>>> [X] Stable - go ahead and release as 8.5.82 (stable)
>>>
>>> Well, I still have a problem. JSP seems to be less functional now with
>>> Java 17+ (at least the one from fedora).
>>>
>>> As a quick test, maybe try
>>> http://127.0.0.1:8080/examples/jsp/include/include.jsp <http://127.0.0.1:8080/examples/jsp/include/include.jsp>
>>> With it I get an error about JDT (we use an older version due to Java 7):
>> Hmm, I don’t get any errors with Java 17.0.2+8-86.
>> I have another question, when doing these tests, what JDK version should I choose for the tests?
>> Should I choose the lowest JDK version supported by the current tomcat version, or is anything above the lowest version ok?
>
> You should use any version that is supported.
>
> I use Java 8 because that's what I (still) run in production.
>
> Theoretically, Java 7 should allow (nearly) all tests to pass, and the product should work properly.
>
> So please feel free to use whatever you have laying around.
>
> Thanks,
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Han,
On 8/9/22 10:46, Han Li wrote:
>
>
>> 2022年8月9日 22:25，Rémy Maucherat <re...@apache.org> 写道：
>>
>> On Tue, Aug 9, 2022 at 12:16 AM Christopher Schultz
>> <chris@christopherschultz.net <ma...@christopherschultz.net>> wrote:
>>>
>>> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>>>
>>> The notable changes compared to 8.5.81 are:
>>>
>>> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
>>> pick up Windows binaries built with OpenSSL 1.1.1q.
>>>
>>> - Enable the use of the FIPS provider for TLS enabled Connectors when
>>> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>>>
>>> - Improvements to HTTP/2 header handling.
>>>
>>> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
>>> Form authentication example.
>>>
>>> Along with lots of other bug fixes and improvements.
>>>
>>> For full details, see the changelog:
>>> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>>>
>>> It can be obtained from:
>>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
>>> The Maven staging repo is:
>>> https://repository.apache.org/content/repositories/orgapachetomcat-1385
>>> The tag is:
>>> https://github.com/apache/tomcat/tree/8.5.82/
>>> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>>>
>>> The proposed 8.5.82 release is:
>>> [ ] Broken - do not release
>>> [X] Stable - go ahead and release as 8.5.82 (stable)
>>
>> Well, I still have a problem. JSP seems to be less functional now with
>> Java 17+ (at least the one from fedora).
>>
>> As a quick test, maybe try
>> http://127.0.0.1:8080/examples/jsp/include/include.jsp <http://127.0.0.1:8080/examples/jsp/include/include.jsp>
>> With it I get an error about JDT (we use an older version due to Java 7):
>
> Hmm, I don’t get any errors with Java 17.0.2+8-86.
>
> I have another question, when doing these tests, what JDK version should I choose for the tests?
> Should I choose the lowest JDK version supported by the current tomcat version, or is anything above the lowest version ok?
You should use any version that is supported.
I use Java 8 because that's what I (still) run in production.
Theoretically, Java 7 should allow (nearly) all tests to pass, and the
product should work properly.
So please feel free to use whatever you have laying around.
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Han Li <ao...@gmail.com>.
> 2022年8月9日 22:25，Rémy Maucherat <re...@apache.org> 写道：
>
> On Tue, Aug 9, 2022 at 12:16 AM Christopher Schultz
> <chris@christopherschultz.net <ma...@christopherschultz.net>> wrote:
>>
>> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>>
>> The notable changes compared to 8.5.81 are:
>>
>> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
>> pick up Windows binaries built with OpenSSL 1.1.1q.
>>
>> - Enable the use of the FIPS provider for TLS enabled Connectors when
>> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>>
>> - Improvements to HTTP/2 header handling.
>>
>> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
>> Form authentication example.
>>
>> Along with lots of other bug fixes and improvements.
>>
>> For full details, see the changelog:
>> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>>
>> It can be obtained from:
>> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
>> The Maven staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomcat-1385
>> The tag is:
>> https://github.com/apache/tomcat/tree/8.5.82/
>> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>>
>> The proposed 8.5.82 release is:
>> [ ] Broken - do not release
>> [X] Stable - go ahead and release as 8.5.82 (stable)
>
> Well, I still have a problem. JSP seems to be less functional now with
> Java 17+ (at least the one from fedora).
>
> As a quick test, maybe try
> http://127.0.0.1:8080/examples/jsp/include/include.jsp <http://127.0.0.1:8080/examples/jsp/include/include.jsp>
> With it I get an error about JDT (we use an older version due to Java 7):
Hmm, I don’t get any errors with Java 17.0.2+8-86.
I have another question, when doing these tests, what JDK version should I choose for the tests?
Should I choose the lowest JDK version supported by the current tomcat version, or is anything above the lowest version ok?
Han.
>
> 09-Aug-2022 16:22:22.856 SEVERE [http-nio-8080-exec-5]
> org.apache.jasper.compiler.JDTCompiler$1.findType Failed to load class
> [java.lang.System]
> org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:406)
> at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:231)
> at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:207)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:174)
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
Re: [VOTE] Release Apache Tomcat 8.5.82
Posted by Rémy Maucherat <re...@apache.org>.
On Tue, Aug 9, 2022 at 12:16 AM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> The proposed Apache Tomcat 8.5.82 release is now available for voting.
>
> The notable changes compared to 8.5.81 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.35 to
> pick up Windows binaries built with OpenSSL 1.1.1q.
>
> - Enable the use of the FIPS provider for TLS enabled Connectors when
> using Tomcat Native 1.2.34 onwards built with OpenSSL 3.0.x onwards.
>
> - Improvements to HTTP/2 header handling.
>
> - Fix CVE-2022-34305, a low severity XSS vulnerability in the
> Form authentication example.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.82/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1385
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.82/
> 237076605ea6b44ec7b97ee1158d5aa7f2f0b53c
>
> The proposed 8.5.82 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.82 (stable)
Well, I still have a problem. JSP seems to be less functional now with
Java 17+ (at least the one from fedora).
As a quick test, maybe try
http://127.0.0.1:8080/examples/jsp/include/include.jsp
With it I get an error about JDT (we use an older version due to Java 7):
09-Aug-2022 16:22:22.856 SEVERE [http-nio-8080-exec-5]
org.apache.jasper.compiler.JDTCompiler$1.findType Failed to load class
[java.lang.System]
org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:406)
at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:231)
at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:207)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:174)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org