Post by @network_is_reliable@mastodon.social

2025-01-28 10:36 UTC

@lberrymage@infosec.exchange @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange > 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. More I think about it, less I like it. Does it mean that developer of com.exampleapp really controls the domain exampleapp.com? I don't think so. You just put trust to another entity. But developer may not be aware of Accrescent at all. He just hosts his repo on github with such package name.

Replies (2)

@network_is_reliable@mastodon.social 2025-01-28 10:44

@lberrymage@infosec.exchange @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange I could trust more or less to IronFox Accrescent badge because it's in the repository. https://gitlab.com/ironfox-oss/IronFox But that whole story of the domain verification does not seem bulletproof for me. Signer key check is a different story.

Open ##3251256
@lberrymage@infosec.exchange 2025-01-28 21:06

@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.

Open ##3251257