Logan Magee

@grote No, it doesn't. I think the program and its introduction have significant issues, but we (Accrescent) are trying to improve it where we can before it becomes more solidified.

Another day of Accrescent, another AOSP bug report: https://issuetracker.google.com/issues/447174551

You might say, "Why are you making file names more than 255 characters long? Do you really need to do that?"

No, no I don't. But someone had to try.

For those curious, I actually came across this because Accrescent was using APK URLs as its APK names to uniquely identify them. Those URLs obviously aren't valid file names, so an exception is thrown (for no clear reason). I "fixed" it locally by hex-encoding the URLs since I suspected it had to do with URLs not being valid paths. That worked locally, but failed in our testing environment which has longer APK URLs. The final fix was to hash the APK URL to ensure the APK name is a constant length and thus always a valid file name. At that point, I figured I should file a bug report.

#android #accrescent

@network_is_reliable@mastodon.social @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange You're right in part at least: an app ID can be arbitrary, and domain verification is not a holistic solution to verifying developer identities. However, it does prevent a malicious actor uploading, say, app.organicmaps to make it seem as if they own organicmaps.app when they don't really control that domain (not to mention the namespacing/collision issues it mitigates). This approach is also taken by other package repositories using reverse domain ID formats such as Maven Central, Flathub, and the Gradle Plugin Portal. There's a chance they could sneak a malicious copy past review with a different app ID. That's why, as I said, it's not a complete solution. But I do think it's a step in the right direction.

@network_is_reliable@mastodon.social @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange Yes. One can download the app's APKs as well as the repository metadata and verify that the signing certificate fingerprints match using apksigner. This is effectively what Accrescent does itself, but it's possible to do outside of Accrescent.

@network_is_reliable@mastodon.social @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange For what it's worth, Accrescent does require domain ownership verification for all new apps now so that you can verify the app ID is published by its respective developer. It is also possible to verify that an app's signing key matches the developer's and is thus cannot be modified by someone else. However, I do acknowledge that it's not very transparent in the UI where an app came from or who submitted it, and that's something we hope to change eventually. We also intend to have more strict and clear policies about impersonation.

I always get excited for new bundletool releases. This time: for device group targeting

https://github.com/google/bundletool/releases/tag/1.18.0

#android #appstore #accrescent