* Marc Prud'hommeaux [2023-02-01 18:12]: > I recently noticed a similar vulnerability in the W3C MiniApp > packaging draft [...]
Interesting, thanks for the info! > But in the context of an Android app, where it sounds like it has > runtime access to the original .apk artifact and signing data, this > could have more serious implications. How much space is available > for abuse in the signing block? Could you embed an entire additional > .apk in there? As far as I know the only size limitation is imposed by the use of a uint64 for the size of the block and the pairs in it [1]. So you can embed plenty in there. Android hopefully has some protections against running native code directly from the signing block, but I think embedding e.g. an entire alternative JavaScript app bundle for a react native app would be fairly trivial to do. - FC P.S. interleaved/bottom posting [2] makes threads on mailing lists like these a lot easier to read than top-posting :) [1] https://source.android.com/docs/security/features/apksigning/v2#apk-signing-block-format [2] https://en.wikipedia.org/wiki/Posting_style
