MaterialFiles Crash when adding SFTP server

When attempting to add an SFTP server through public key authentication, the app crashes immediately. It re-opens afterward, but the server isn't added.

Crash report:

type: crash
osVersion: google/panther/panther:13/TQ3A.230901.001/2023091800:user/release-keys
package: me.zhanghai.android.files:33
process: me.zhanghai.android.files
processUptime: 19388 + 377 ms
installer: dev.imranr.obtainium

java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.String.startsWith(java.lang.String)' on a null object reference
	at g6.a.d(SourceFile:66)
	at ad.a.e(SourceFile:1)
	at me.zhanghai.android.files.storage.EditSftpServerFragment.c1(SourceFile:321)
	at z9.b.onClick(SourceFile:65)
	at android.view.View.performClick(View.java:7542)
	at com.google.android.material.button.MaterialButton.performClick(SourceFile:10)
	at android.view.View.performClickInternal(View.java:7519)
	at android.view.View.-$$Nest$mperformClickInternal(Unknown Source:0)
	at android.view.View$PerformClick.run(View.java:29476)
	at android.os.Handler.handleCallback(Handler.java:942)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:201)
	at android.os.Looper.loop(Looper.java:288)
	at android.app.ActivityThread.main(ActivityThread.java:7940)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
	at com.android.internal.os.ExecInit.main(ExecInit.java:49)
	at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
	at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:355)

Oct 01 '23 15:10 cohesive-flight

So I did a bit of testing, and it looks like this is an issue specifically with ed25519 keys when there's no passphrase set. It works fine with passwordless RSA keys, but not with passwordless ed25519 keys. I tried testing this with other apps, like FTPClient, and it also has issues with passwordless ed25519 keys. It doesn't crash, but it does encounter a NullPointerException like yours does (similar library used?).

I should also note that even though it didn't crash after adding a passphrase, the server's file system wouldn't load with either key types. The only way it would was if I used password authentication rather than public key authentication. I might create a separate issue for this specifically.

Oct 01 '23 21:10 cohesive-flight

Can't reproduce, the following ed25519 private key that I just generated worked fine without crashing:

I'll probably need at least a private key of the same format as yours to reproduce.

Oct 02 '23 02:10 zhanghai

It looks like I was wrong. This was simply a formatting issue when copying the private key from Termux. It had extra spaces after the second-to-last line and missed an empty new line in between, so it was hard to notice. I would consider adding a warning when a user attempts to add an improperly formatted key.

The issue of the file system not loading when using public key authentication still persists.

Oct 02 '23 08:10 cohesive-flight

It had extra spaces after the second-to-last line and missed an empty new line in between, so it was hard to notice.

Could you change my key in https://github.com/zhanghai/MaterialFiles/issues/1035#issuecomment-1742328633 to show how that actually looks like? I'm confused because there's no empty line in between my key.

The issue of the file system not loading when using public key authentication still persists.

I'll try to reproduce later.

Oct 02 '23 08:10 zhanghai

I'm confused because there's no empty line in between my key

Oh no, I was referring to my initial key. Your success with yours prompted me to create a new one to see if I made a mistake anywhere.

This was my key:

But when copying it from Termux, it became like this:

The empty line and extra spaces I mentioned earlier were based on a text comparison site I used, but it seems that the issue was because the end message was not placed on its own line at the end.

Oct 02 '23 09:10 cohesive-flight

This has been fixed in upstream SSHJ 0.36.0 OpenSSHKeyV1KeyFile.readKeyFile(), however that version also started to require Java 8 which made it incompatible with this app...

Feb 28 '24 08:02 zhanghai