Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SHA-1 hashes not present anymore in API jar files #737

Closed
theofficialgman opened this issue Feb 22, 2022 · 1 comment
Closed

SHA-1 hashes not present anymore in API jar files #737

theofficialgman opened this issue Feb 22, 2022 · 1 comment

Comments

@theofficialgman
Copy link

theofficialgman commented Feb 22, 2022

Version

3.3.0 (nightly), 3.2.3

Platform

Linux x64, Linux arm64, Linux arm32, macOS x64, macOS arm64, Windows x64, Windows x86, Windows arm64

JDK

irrelevant

Module

All

Bug description

Prior to LWJGL 3.2.3, SHA-1 hashes were available in the api only jar files (in addition to the natives). Beginning in lwjgl 3.2.3, those hashes are no longer available and are only available in the corresponding native JAR files. Since lwjgl 3.2.3 first introduced multiple new architectures on the same platform (armhf/arm64 linux), the old way of packing the .sha1 files into the root of the api JAR would not work anyway even if it was implemented.

Is this an oversight or intentional? It seems to me that builtin hash check has been skipped ever since 3.2.3 with this change:

/**
* Compares the shared library hash stored in the classpath, with the hash of the actual library loaded at runtime.
*
* <p>This check prints a simple warning when there's a hash mismatch, to help diagnose installation/classpath issues. It is not a security feature.</p>
*
* @param context the class to use to discover the shared library hash in the classpath
* @param libFile the library file loaded
*/
private static void checkHash(Class<?> context, Path libFile) {
if (!CHECKS) {
return;
}
try {
URL classesURL = null;
URL nativesURL = null;
Enumeration<URL> resources = context.getClassLoader().getResources(libFile.getFileName() + ".sha1");
while (resources.hasMoreElements()) {
URL url = resources.nextElement();
if (NATIVES_JAR.matcher(url.toExternalForm()).find()) {
nativesURL = url;
} else {
classesURL = url;
}
}
if (classesURL == null) {
return;
}
byte[] expected = getSHA1(classesURL);
byte[] actual = DEBUG || nativesURL == null
? getSHA1(libFile)
: getSHA1(nativesURL);
if (!Arrays.equals(expected, actual)) {
DEBUG_STREAM.println(
"[LWJGL] [ERROR] Incompatible Java and native library versions detected.\n" +
"Possible reasons:\n" +
"\ta) -Djava.library.path is set to a folder containing shared libraries of an older LWJGL version.\n" +
"\tb) The classpath contains jar files of an older LWJGL version.\n" +
"Possible solutions:\n" +
"\ta) Make sure to not set -Djava.library.path (it is not needed for developing with LWJGL 3) or make\n" +
"\t sure the folder it points to contains the shared libraries of the correct LWJGL version.\n" +
"\tb) Check the classpath and make sure to only have jar files of the same LWJGL version in it.");
}
} catch (Throwable t) {
if (DEBUG) {
apiLog("Failed to verify native library.");
t.printStackTrace();
}
}
}

Stacktrace or crash log output

No response

@theofficialgman theofficialgman changed the title SHA-1 hashes SHA-1 hashes not present anymore in API jar files Feb 22, 2022
@Spasi Spasi closed this as completed in ab591eb Feb 24, 2022
@Spasi
Copy link
Member

Spasi commented Feb 24, 2022

@theofficialgman Thanks!

The first 3.3.2 snapshot will include the missing hashes and incompatibility detection should be working. The .sha1 and .git files have also been moved under META-INF in the LWJGL JAR files.

theofficialgman pushed a commit to theofficialgman/lwjgl3 that referenced this issue Feb 27, 2022
Also moved .sha1 and .git files under the META-INF folder in LWJGL JAR
files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants