musings about a different(?) reported problem

Made no headway on any of them, unfortunately.

NOTES

@@ -1292,27 +1292,89 @@ one that looks relevant is "scoped storage enforcement", which is just
 the /sdcard nightmare that we've known all along is getting worse.
 
 
+January 17, 2021.
 
+I have had a little luck today...  I tested a little with
+requestLegacyExternalStorage and API 29, on an emulated Android 11, and
+it seems to work.  Users will likely need to use the new "Enable /sdcard"
+menu option.
 
-XXX - Remy B says I try going back to SDK 29 and doing requestLegacyExternalStorage, and then when i am forced to upgrade to SDK 30, by then MANAGE_EXTERNAL_STORAGE should be available?
-XXX - Rich D has problem with ssh-rsa key "Exit before auth from <192.168.10.123:58978>:(user 'user', 0 fails): Non-matching signing type" but ssh -vvv on other side says "debug1: Authentication succeeded (publickey)." before it notices the remote closed the connection.  client is mint 18.3 (https://svn.dd-wrt.com/changeset/44047)
-XXX - Vitalii suggests giving an error message for unrecognized key types (ed25519) that are encountered in authorized_keys, so the user doesn't have to stab in the dark
+Also, it turns out to be trivial to honor the MY_PACKAGE_REPLACED
+(package upgrade) intent using the same receiver as BOOT_COMPLETED, which
+is going to be great for people going forward.
+
+...
+
+I have been banging on the problem people have reported with
+"Non-matching signing type." with older versions of OpenSSH.  I've been
+told it's the OpenSSH 7.2p2 that ships stock with Ubuntu 16.04 and Mint
+18.3.  Rich D did the legwork and found it is probably
+https://svn.dd-wrt.com/ticket/7179
+
+There is a new check for expect_sigtype != sigtype in dropbear 2020.81.
+The fix the dd-wrt guys came up with is simply to disable that check if
+expect_sigtype == DROPBEAR_SIGNATURE_RSA_SHA256.  I don't like simply
+disabling the check, because I don't know what the role of the check is.
+I don't want to be a blind fool.
+
+It sounds like there's one protocol string "ssh-rsa" that can also be
+used to represent "rsa-sha2-256".  I did not bother to trace through how
+that string gets converted into these numeric values.  But at the bottom
+of http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030200.html
+it says the actual signature is DROPBEAR_SIGNATURE_RSA_SHA1.  This makes
+sense from grepping around the dropbear source:
+
+   {"rsa-sha2-256", DROPBEAR_SIGNATURE_RSA_SHA256, NULL, 1, NULL},
+   {"ssh-rsa", DROPBEAR_SIGNATURE_RSA_SHA1, NULL, 1, NULL},
+   DROPBEAR_SIGNATURE_RSA_SHA1 = 100, /* ssh-rsa signature (sha1) */
+   DROPBEAR_SIGNATURE_RSA_SHA256 = 101, /* rsa-sha2-256 signature. has a ssh-rsa key */
+
+So confusion between those two sounds likely to me.
+
+...
+
+Triaged the crashes again.  crash.20200109 is the only one that bothers
+me.  It will probably continue at a low incidence until I figure out
+what's causing it.
+
+...
+
+Oh and!  There is one more interesting problem, reported by Brad R and
+Andreas S.  Maybe it's different problems??  The thing in common is that
+they aren't seeing anything displayed from the dropbear.err file, and
+then they aren't able to connect.  But Brad R says he used netstat and it
+really is listening on the port, and he sent me a ssh -vvv report that
+seems to show the server dropping connection after the client has
+received an SSH2_MSG_KEXINIT, while waiting for a response to
+SSH_MSG_KEXDH_INIT. So I guess the server must be running?
+
+Andreas S concluded that the server isn't running, due to the lack of
+displayed dropbear.err output.  That made sense to me at first, but now I
+think maybe his server is also running, just not working??
+
+So one possible explanation for both of them is that they have put their
+dropbear directory under /sdcard, and the external storage charley
+foxtrot has made them unable to access their server's host key at the
+same time as making them unable to diagnose the problem (unable to read
+dropbear.err).  I haven't yet asked either of them if they have
+configured it to use /sdcard.
+
+But I'm worried there's something more fundamental going on.  We'll see
+if they report any progress with version 27 that I just released.
+
+
+XXX - crash.20200109
 XXX - on android 6 (duckling moto g2), the notification is white-on-white?
 XXX - test Settings and Notifications colors in Pie (or Quiche?) "dark mode" for Alexander Chobot, and for Fionn Behrens (https://developer.android.com/guide/topics/ui/look-and-feel/darktheme)
-XXX - crash.20200109
 XXX - if the unlink(authorized_keys) fails, or if the open() fails for permission reasons, generate a Toast for the user. (confirmed that restorecon -F authorized_keys works)
-XXX - ability to dynamically request <uses-permission-sdk-23 android:name="android.permission.SEND_SMS" /> (and if that's dynamic, could we make the install app permission also dynamic??)
-XXX - restart the daemon on app upgrade
-       <receiver android:name="com.google.android.apps.youtube.app.PackageReplacedReceiver">
-            <intent-filter>
-                <action android:name="android.intent.action.MY_PACKAGE_REPLACED"/>
-            </intent-filter>
-        </receiver>
 XXX - why doesn't "ssh -R 2223:192.168.1.254:80 mouse" work?
 
+XXX - when i am forced to upgrade to SDK 30, request MANAGE_EXTERNAL_STORAGE permission
+XXX - Vitalii suggests giving an error message for unrecognized key types (ed25519) that are encountered in authorized_keys, so the user doesn't have to stab in the dark
+XXX - ability to dynamically request <uses-permission-sdk-23 android:name="android.permission.SEND_SMS" /> (and if that's dynamic, could we make the install app permission also dynamic??)
+
 XXX - figure out how to force a screen refresh on eink devices (onyx boox) when the password is displayed (Roman)
 XXX - Tasker on Android 9 can't trigger the new START/STOP intents? (Kumaran)
-XXX - test file renaming in /storage/emulated/0/download on Quiche for Ben Reaves
 
 --- new release
 

app/build.gradle

@@ -27,8 +27,8 @@ android {
         minSdkVersion 17
         targetSdkVersion 29
 
-        versionCode 26
-        versionName "26"
+        versionCode 27
+        versionName "27"
     }
 
     buildTypes {

app/src/main/AndroidManifest.xml

@@ -37,7 +37,11 @@
 	    <intent-filter>
 		<action android:name="android.intent.action.BOOT_COMPLETED" />
 	    </intent-filter>
-	</receiver>
+	    <intent-filter>
+		<action
+		    android:name="android.intent.action.MY_PACKAGE_REPLACED" />
+	    </intent-filter>
+        </receiver>
 	<receiver android:name="StartReceiver">
 	    <intent-filter>
 		<action android:name="org.galexander.sshd.START" />

crash.20200109

@@ -2,7 +2,7 @@ Yesterday, 7:03 PM on app version 24
 OnePlus OnePlus 7T (OnePlus7T), Android 10
 Report 1 of 3
 
-android.app.RemoteServiceException: 
+android.app.RemoteServiceException:
   at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2038)
   at android.os.Handler.dispatchMessage (Handler.java:107)
   at android.os.Looper.loop (Looper.java:214)
@@ -10,3 +10,56 @@ android.app.RemoteServiceException:
   at java.lang.reflect.Method.invoke (Native Method)
   at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:516)
   at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:950)
+
+
+2021/01/17 - confirmed this is still happening with version 26 of the
+app, reported on Android 8.1 (SDK 27) and Android 10 (SDK 29).
+
+https://stackoverflow.com/questions/51222082/why-do-i-get-remoteserviceexception-for-creating-updating-a-notification
+suggests it has something to do with the Notification passed to
+startForeground(), but their "workaround" was to only modify the
+Notification from the Service thread, which we already do.
+
+I could not reproduce it under the emulator with Android 8.1 and starting
+the service is several different contexts, including using the START
+broadcast after the app had been force stopped, or when the service had
+started because the package had just been updated (UI not displayed yet).
+I also tested launching the PendingIntent from those contexts.
+
+Looking at ActivityThread.java that came with my SDK and it looks like
+RemoteServiceException() is just called whenever handleMessage() is
+passed a msg.what == SCHEDULE_CRASH, which is sent from
+ApplicationThread.scheduleCrash(), which is called (indirectly) from:
+   ActivityStackSupervisor.PendingActivityLaunch.sendErrorResult()
+      ... ultimately called when there's an exception during a
+      PendingIntent launch, with the string from that exception??
+   BroadcastQueue.performReceiveLocked() on a RemoteException with the
+      string "can't deliver broadcast"
+   ActivityManagerShellCommand.runCrash() with "shell-induced crash"
+   ServiceRecord.postNotification() with "Bad notification for startForeground:"
+   ActiveServices.serviceForegroundCrash() with
+      "Context.startForegroundService() did not then call
+      Service.startForeground():"
+   NativeCrashListener.NativeCrashReporter.run() but I'm not sure it
+      actually makes it into the same crashApplication() or not?
+   RuntimeInit.wtf() not sure where this error winds up either but
+
+Most of those, I think, would be pretty good about putting a message
+there so I'm not clear why no message is provided.
+
+Googling some more:
+   https://github.com/commons-app/apps-android-commons/issues/1877
+      failed to set a NotificationChannel but I think I've already
+      crossed that bridge.
+   https://www.xspdf.com/resolution/50183960.html
+      the XML layout for their Notification specified a manual height for
+      the root element??  the outer element for mine is wrap_content, but
+      one of the contents is an ImageView with a manual size (60dp x
+      60dp) ??  (and many others at this URL) Could maybe be a problem
+      with the res/drawable for the notification icon?
+
+Crashlytics would apparently provide more info -- I'm not clear why
+Google's crash reporter isn't giving me the RemoteServiceException
+message on its own though!  But Crashlytics smells like bloatware to me
+and from looking at the source (/usr/src/firebase-android-sdk), I didn't
+immediately see how it could change the reporting of this sort of crash.

crash.20200122

@@ -7,3 +7,7 @@ pid: 0, tid: 0 >>> org.galexander.sshd <<<
 backtrace:
   #00  pc 000000000001a6ac  /system/lib/libc.so (abort+63)
   #01  pc 0000000000020c79  /system/lib/libc.so (sigprocmask+48)
+
+
+2021/01/17 - Looking at the play console today, this crash is not in the
+last 60 days which is all it will show me.  So I guess it's rare.

crash.20201123

@@ -0,0 +1,23 @@
+java.lang.IllegalStateException: 
+  at android.os.Parcel.createException (Parcel.java:1958)
+  at android.os.Parcel.readException (Parcel.java:1918)
+  at android.os.Parcel.readException (Parcel.java:1868)
+  at android.app.IActivityManager$Stub$Proxy.reportAssistContextExtras (IActivityManager.java:7107)
+  at android.app.ActivityThread.handleRequestAssistContextExtras (ActivityThread.java:3212)
+  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1764)
+  at android.os.Handler.dispatchMessage (Handler.java:106)
+  at android.os.Looper.loop (Looper.java:193)
+  at android.app.ActivityThread.main (ActivityThread.java:6669)
+  at java.lang.reflect.Method.invoke (Native Method)
+  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493)
+  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:858)
+Caused by: android.os.RemoteException: 
+  at android.app.ContextImpl.startServiceCommon (ContextImpl.java:1577)
+  at android.app.ContextImpl.startServiceAsUser (ContextImpl.java:1549)
+  at com.android.server.am.ActivityManagerService.reportAssistContextExtras (ActivityManagerService.java:14185)
+  at android.app.IActivityManager$Stub.onTransact$reportAssistContextExtras$ (IActivityManager.java:10882)
+  at android.app.IActivityManager$Stub.onTransact (IActivityManager.java:1953)
+
+
+2021/01/17 - reported exactly once on an unknown Android 9 device with
+version 24 of SimpleSSHD.  A mystery I will leave unless it recurs.

crash.20201225

@@ -0,0 +1,33 @@
+java.lang.UnsatisfiedLinkError: 
+  at java.lang.Runtime.loadLibrary0 (Runtime.java:1016)
+  at java.lang.System.loadLibrary (System.java:1669)
+  at org.galexander.sshd.SimpleSSHDService.<clinit> (SimpleSSHDService.java:185)
+  at org.galexander.sshd.SimpleSSHDService.is_started (SimpleSSHDService.java:86)
+  at org.galexander.sshd.SimpleSSHD.update_startstop_prime (SimpleSSHD.java:107)
+  at org.galexander.sshd.SimpleSSHD.onResume (SimpleSSHD.java:49)
+  at android.app.Instrumentation.callActivityOnResume (Instrumentation.java:1412)
+  at android.app.Activity.performResume (Activity.java:7302)
+  at android.app.ActivityThread.performResumeActivity (ActivityThread.java:3776)
+  at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:3816)
+  at android.app.servertransaction.ResumeActivityItem.execute (ResumeActivityItem.java:51)
+  at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:145)
+  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:70)
+  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1808)
+  at android.os.Handler.dispatchMessage (Handler.java:106)
+  at android.os.Looper.loop (Looper.java:193)
+  at android.app.ActivityThread.main (ActivityThread.java:6669)
+  at java.lang.reflect.Method.invoke (Native Method)
+  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:518)
+  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:858)
+
+
+2021/01/17 - This has been reported from two different users, both on
+OnePlus3 phone running Android 9.  It was reported both with version 16
+and 24 of SimpleSSHD.  It seems to be from where SimpleSSHDService tries
+to load simplesshd-jni, which is the core JNI for the whole thing and the
+only one that is linked in the normal way.  It is a normal processor
+(snapdragon 820).
+
+Since it's just the one kind of phone, I think I'm gonna ignore it.  It's
+probably some problem with how libc or JNI library is linked, but I can't
+imagine what that problem is.

doc/index.html

@@ -97,7 +97,7 @@ greater than 1024 (because SimpleSSHD does not have root).</dd>
 
 <dt>Buffer hack for rsync+SuperSU</dt>
 <dd>A bug in SuperSU interacts with an infelicity in rsync to cause an
-occasional deadlock.  This is a real pain because I use SuperSU+rsync 
+occasional deadlock.  This is a real pain because I use SuperSU+rsync
 for system-wide backups, which will always eventually trigger the
 deadlock.  To work around this, there is a "Buffer hack" option that
 should be enabled if you use rsync with SuperSU.  It adds a miniscule
@@ -170,6 +170,10 @@ or later if <b>Settings</b> -> <b>Foreground Service</b> is enabled.</p>
 <p>You may need to specify <tt>--user 0</tt> depending on the context:
 <pre>am broadcast --user 0 -a org.galexander.sshd.START org.galexander.sshd</pre></p>
 
+<p>And if Android is ignoring your broadcasts because the app was never started yet (or was force stopped), you may try (it's all arbitrary to me!):
+<pre>am broadcast --user 0 -a org.galexander.sshd.START org.galexander.sshd/.StartReceiver</pre></p>
+
+
 <p>If you are getting an error from <tt>am</tt> like:
 <pre>cmd: Failure calling service activity: Failed transaction (2147483646)</pre>
 it can probably be solved by disassociating <tt>am</tt> from the ssh
@@ -221,6 +225,7 @@ harmless.
 <h2>Change Log</h2>
 
 <ul>
+<li> <b>2021/01/17 Version 27:</b> New approach to accessing /sdcard.  Automatically re-start on package upgrade if Start on Boot enabled.  Fix "Non-matching signing type" error with older ssh clients.
 <li> <b>2020/12/29 Version 26:</b> Fix ed25519 host key creation.
 <li> <b>2020/12/29 Version 25:</b> Fix compatibility with WinSCP.  Update to upstream Dropbear 2020.81 -- adding ed25519 support!
 <li> <b>2020/01/01 Version 24:</b> Fix crash with "Start on Open" on Android 9. New TV icon.  Improve performance.
@@ -285,6 +290,7 @@ me:<br>
 <li><a href="SimpleSSHD-23.apk">SimpleSSHD-23.apk</a>
 <li><a href="SimpleSSHD-24.apk">SimpleSSHD-24.apk</a>
 <li><a href="SimpleSSHD-26.apk">SimpleSSHD-26.apk</a>
+<li><a href="SimpleSSHD-27.apk">SimpleSSHD-27.apk</a>
 </ul></p>
 
 </body></html>

dropbear/signkey.c

@@ -657,7 +657,13 @@ int buf_verify(buffer * buf, sign_key *key, enum signature_type expect_sigtype,
 	sigtype = signature_type_from_name(type_name, type_name_len);
 	m_free(type_name);
 
-	if (expect_sigtype != sigtype) {
+	if (((expect_sigtype == DROPBEAR_SIGNATURE_RSA_SHA256) &&
+	     (sigtype == DROPBEAR_SIGNATURE_RSA_SHA1)) ||
+	    ((expect_sigtype == DROPBEAR_SIGNATURE_RSA_SHA1) &&
+	     (sigtype == DROPBEAR_SIGNATURE_RSA_SHA256))) {
+		/* ignore mismatch between different flavors of ssh-rsa
+		 * - Greg 2021/01/17 */
+	} else if (expect_sigtype != sigtype) {
 			dropbear_exit("Non-matching signing type");
 	}