Skip to content

Add verification info to download info #16

@lberrymage

Description

@lberrymage

The way Accrescent clients currently verify app downloads as legitimate is downloading a JSON index at the hardcoded endpoint https://repo.accrescent.app/repodata.1.json and its signature at https://repo.accrescent.app/repodata.1.json. It then verifies the signature and subsequently uses the index for verifying the minimum version code and signing certificate hash of the downloaded app. This approach is problematic for a number of reasons:

  • The index and its signature are separate files, effectively requiring us to never cache them so that clients always see them updated (nearly) simultaneously so that signature verification reliably works.
  • Clients must download the entire index of all apps on Accrescent, which may grow to be rather large in size eventually. Compression could help drastically, but it's not necessary for clients to have verification info for apps they never download.
  • Since the index contains all apps on Accrescent, it isn't possible to have apps completely hidden from certain users, e.g., for private apps published only internally since the app IDs are known.
  • We don't require JSON anywhere else in Accrescent's API since the migration to the gRPC-based app store API, so requiring the use of both a gRPC API and a JSON API in conjunction with each other isn't consistent.
  • This index is a static file that is currently updated manually updated out-of-band, making it unpleasant to maintain.

Instead, I propose providing verification information where it actually matters: the download information response message. This would solve all of the above issues in the following ways:

  • Consistent caching is possible since verification info is provided directly with information about the package files it applies to.
  • Verification info is provided on-demand in an app-specific manner, so clients download only the information they need.
  • Since verification info is app-specific and on-demand, we can provide it only when the user has authorization to download the app, preventing published app ID information leaks.
  • The verification info is provided directly in a gRPC response, making pairing the app store API with a separate JSON API unnecessary.
  • Since the verification information is served by the server, we can update it dynamically and through the same systems used for updating other information in Accrescent, centralizing and simplifying maintenance.

Some implementation notes:

  • Signed verification information provided in a gRPC message MUST be encoded in a bytes type because protobuf serialization is not canonical.
  • For backward compatibility with old Accrescent clients, apps published on Accrescent after this change is implemented should not be visible to such old Accrescent clients. Otherwise users on those clients may attempt to install an app that has verification information only in the download info response (which they haven't been updated to understand) when they expect it in the JSON index and installation will fail.

Unresolved questions:

  • It is unclear how we should handle signature rotation. This solution should probably support it off the bat to ensure we don't run into backward compatibility issues adding support later.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions