Jira Service Desk 4.5.x upgrade notes
Below are some important notes on upgrading to Jira Service Desk 4.5. For details on the new features and improvements in this release, see the Jira Service Desk 4.5.x release notes.
Summary of changes
Upgrade notes
We normally do not introduce new features in the Long Term Support release but rather consolidate the ones we've introduced since the last Enterprise releases. See our change log for all the features and fixes between the last LTS releases. Learn more
Security advice: Allowing customers to raise requests
We’ve published a security advice regarding the setting “Anyone can email the service desk or raise a request in the portal” that can be set in Administration > Applications > Jira Service Desk configuration. If you’re using this setting, make sure to read it. For more info, see Managing access to your service project.
4.5.17: Bundled JRE disables secure connections to MySQL Community Edition 5.7.27 or older over TLS versions 1 and 1.1
Jira Service Desk 4.5.17 binary installers are bundled with the AdoptOpenJDK 8u291 JRE, which ships with TLS versions 1 and 1.1 disabled by default. This prevents secure connections with MySQL Community Edition 5.7.27 or older compiled with yaSSL.
You're not affected by this issue if:
- You’re running MySQL Enterprise Edition
- You’re running MySQL Community Edition 5.7.27 compiled with OpenSSL
- You haven’t enabled secure connections in MySQL Community Edition
- You’re running Jira using a JRE version lower than 8u291 or 11.0.11
To ensure that Jira can establish a secure connection with your MySQL database after the upgrade, switch to a version of MySQL Community Edition that supports TLS 1.2. You can choose one of the following solutions:
Recommended solution: Upgrade to MySQL Community Edition 5.7.28 or newer
Because the binary distributions of MySQL Community Edition 5.7.27 and older are compiled with yaSSL, they do not support TLS 1.2 by default. We recommend that you upgrade to MySQL Community Edition 5.7.28 or newer (this version uses the OpenSSL library), and then allow secure connections over TLS 1.2 by either:
- Upgrading the MySQL Connector/J driver to version 8.0.19 or newer.
- Adding the
enabledTLSProtocols=TLSv1.2
parameter to the MySQL JDBC connection string indbconfig.xml
.
For more information, see:
Solution 2: Recompile MySQL Community Edition 5.7.27 or older with OpenSSL
Alternatively, you can recompile version MySQL Community Edition 5.7.27 or older with OpenSSL, and then allow secure connections over TLS 1.2 by either:
- Upgrading the MySQL Connector/J driver to version 8.0.19 or newer.
- Adding the
enabledTLSProtocols=TLSv1.2
parameter to the MySQL JDBC connection string indbconfig.xml
.
For more information, see:
- MySQL 5.7 Reference Manual — 2.9.6 Configuring SSL Library Support
- Connecting Jira applications to MySQL 5.7
Solution 3: Re-enable TLS 1 and 1.1 in Java
The TLS 1 and 1.1 protocols are insecure. Atlassian does not recommend using this solution in the long term.
If required, you can re-enable support for TLS 1 and TLS 1.1 in Java by removing the TLSv1
and TLSv1.1
entries from the jdk.tls.disabledAlgorithms
property in <JAVA_HOME>/lib/security/java.security
.
4.5.15: Changes in startup files
We've changed several startup files to change the format of GC logs produced by Jira while running with Java 11. Without the change, the logs are impossible to parse with the GCViewer tool and can be frustrating for an admin to work with.
We've changed the time,uptime
to tags,time,uptime,level
in the following files:
bin/set-gc-params.sh
file on Linuxbin/set-gc-params.bat
file on Windowsbin/set-gc-params-service.bat
file on Windows
If you don't have any custom changes in those files, you don't need to take any cation. If you do, you'll need to copy your changes to the new files on upgrade.
4.5.9: OAuth 2.0 for incoming mail
This feature was backported from Jira Service Desk 4.10.
Google and Microsoft are planning to deprecate basic authentication. This means that if you’re using one of these email providers (as your mail server in Jira) and create requests or issues via email, you will need to reconfigure your mail servers to use the OAuth 2.0 authentication method instead.
Follow these steps to use OAuth 2.0:
All Jira applications: Integrate Jira with OAuth 2.0. Learn more
Jira Core and Jira Software projects: Reconfigure mail servers to use OAuth 2.0. Learn more
Jira Service Desk projects: Reconfigure email channels to use OAuth 2.0. Learn more
4.5.4: Support for PostgreSQL 10
We've added PostgreSQL 10 to the list of supported platforms. For more info, see Supported platforms.
4.5.4: G1 GC enabled by default for Java 11
If you’re running Jira with Java 11, Garbage First Garbage Collection (G1 GC) will be enabled by default. We’ve already been recommending this method when tuning garbage collection, so now you’ll get it out of the box. G1 GC is more efficient and improves performance, especially in environments with large Java heap.
Java version | Default GC | Recommended GC |
---|---|---|
Java 11 | G1 GC |
|
Java 8 | ParallelGC | ParallelGC |
*Our performance tests have shown that you might benefit from ParallelGC if you have a relatively small Java heap. The difference is not big, but you can consider switching back to ParallelGC if you’re having problems with performance.
4.5.4: Changes in the issue collector
The upcoming update of the Chrome browser introduces new cookie security features, which would essentially break the issue collectors embedded on separate domains. We’ve fixed this problem, but this brought some changes to how issue collectors work:
You can no longer match the submitter’s user session to make them the issue reporter. You can still match them by using their email address.
You don’t have to enable 3rd party cookies to make the issue collector work. We’ve removed this requirement, also dropping some error messages that reminded about it.
The project and issue key will no longer be displayed in the success message after submitting feedback (unless the project is open to Anyone on the web). We did this to improve security by not disclosing information about projects and issues.
For more info on the issue collector, see Using the issue collector.
Increase your pool-max-size before upgrade
If you're upgrading from Jira Service Desk 3.x to 4.x we recommend changing the pool-max-size
parameter to 40 in your dbconfig.xml before the upgrade. This prevents re-index ending up with the ResultSet closed error, especially when you use SQL Server or PostgreSQL as your database. For information on implementing the change, see Tuning database connections.
Known vulnerability in the BKS-V1 keystore format
If you’re running Jira over SSL, we’d like to bring your attention to a security vulnerability of the BKS-V1 keystore format, provided by the BouncyCastle library. We strongly recommend that you don’t use it in your Jira instance. Learn more
End of support announcements
In Jira Service Desk 4.5, we're making the following changes:
- Advance notice: Deprecating Internet Explorer 11. Jira Service Desk 4.5 will be the last release to support this version of IE. That means that after it reaches "end of life" in 2021, we'll stop all support related to IE 11, and we'll no longer test Jira on IE 11.
For more information, see End of support announcements.
App developers
See Preparing for Jira 8.5 for any important changes regarding apps.
Upgrade procedure
We've prepared a dedicated upgrade guide for upgrading between Enterprise releases. See Long Term Support release upgrade guide.