[pkg] fix: drop dependency on ca-certificates-java #61
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Related to ev3dev-lang-java/ev3dev-lang-java#728 (comment) The problem is that ca-certificates-java relies on jri-N-ev3 for the java-command; however jri-N-ev3 also depends on ca-certificates java. The proper fix would be to specify a self-dependency as outlined in adoptium/installer#105 (comment) . This will probably somehow break the dependency cycle so that jri-N-ev3 is installed first and only then the ca-certificates-java package gets installed. This is nice, but the installation failure damages the system cacerts file and simple --reinstall is *not* enough to fix this, instead AFAIK all java packages have to be uninstalled and then reinstalled again. Let's instead ship the cacerts that ship with other AdoptOpenJDK builds. This will fix cacerts error from the start. If the user wants to use ca-certificates-java, this actually makes it possible to do so - they just need to install the package after jri-N-ev3 and then symlink /usr/lib/jvm/jri-N-ev3/lib/security/cacerts to /etc/ssl/certs/java/cacerts which is managed by ca-certificates-java. Nothing is perfect, though. The potential issue with Adopt's CA certificates is that they seem pretty old (~ 3 years). It seems that this is going to change: adoptium/adoptium-support#13 This change will however impact the JDK build script and not the packaging script.
Member
|
I need to understand better the change.
|
Contributor
Author
This is because JDK is self-contained and so it does not have cacerts symlinked to /etc/ssl/certs/java/cacerts (location on Debian where the cacerts are managed by ca-certificates-java).
No, there will be no effect from this PR, as the JDK bundles the cacerts that were used when building Java. This change just brings the certificates from JDK to JRI too. |
Contributor
Author
|
I have not included the installation failure, here it is: The "fix" does not really work, as the trust store is corrupted: CA certificate database corruption can be discovered by running this command: Compared to |
Member
|
I am going to read in detail the comments, tomorow, I will approve it. |
Member
|
Note: Good engineering research :) |
Contributor
Author
|
I have created an alternative fix for the issue: #64. However it has its issues too. |
Member
|
Wait, tomorrow we will discuss. 2 CPUS process better the issues. |
Open
5 tasks
Contributor
Author
|
Continuing in ev3dev-lang-java/ev3dev-lang-java#731 |
Member
|
Hi @JakubVanek, what is the value for this particular PR. I observe that the build remove the dependency wit cacerts but later, it is necessary another PR. Why not merge all PR in a unique PR. It could be better to understand the whole picture. This one is clear: Remove the dependency. |
Contributor
Author
Yes, it makes things a little more complicated, but it follows single reponsibility principle. (another summary: ev3dev-lang-java/ev3dev-lang-java#731 (comment))
#61 and #64 are two different solutions to one problem, #62 is a solution to another problem that we haven't yet experienced but might (outdated cacerts in JDK/JRI tarpkg)
This is not that clear, ev3dev-lang-java/ev3dev-lang-java#731 (comment) lists the pros and cons. |
Closed
4 tasks
Contributor
Author
|
reopening |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to ev3dev-lang-java/ev3dev-lang-java#728 (comment)
The problem is that the
ca-certificates-javapackage relies onjri-N-ev3for thejavacommand; howeverjri-N-ev3also depends onca-certificates java.The proper fix would be to specify a self-dependency as outlined in adoptium/installer#105 (comment). This will probably somehow break the dependency cycle so that
jri-N-ev3is installed first and only then theca-certificates-javapackage gets installed.This is nice, but the installation failure damages the system
cacertsfile and simpleapt install --reinstallis not enough to fix this, instead AFAIK all java packages have to be uninstalled and then reinstalled again.Let's instead ship the cacerts that ship with other AdoptOpenJDK builds. This will fix cacerts error from the start. If the user wants to use
ca-certificates-java, this actually makes it possible to do so -they just need to install the package after
jri-N-ev3and then symlink/usr/lib/jvm/jri-N-ev3/lib/security/cacertsto/etc/ssl/certs/java/cacertswhich is managed byca-certificates-java.Nothing is perfect, though. The potential issue with Adopt's CA certificates is that they seem pretty old (~ 3 years). It seems that this is going to change: adoptium/adoptium-support#13 That change will however impact the JDK build script and not the packaging script.