GiftedHacker/tangem-app-android-audited
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
tangem-app-android-audited/AUDIT.md

28 KiB
Raw Permalink Blame History

Security Audit Report

Tangem Android Wallet — Source Code Review
Subject tangem-app-android — Tangem cryptocurrency wallet for Android
Upstream https://github.com/tangem/tangem-app-android
Commit reviewed 358144ee61a (branch master) — confirmed identical to upstream master (§6.5)
Report date 17 August 2026
Revised 17 August 2026 — §3.1, §3.6, O-3 corrected; §6.5 resolved. See "Revisions" below
Companion report APKANALYSIS.md — binary comparison against Tangem's official v6.1.2 release APK
Review type Static source code review (manual, targeted)
Codebase size ~292 Gradle modules · 7,719 Kotlin files · 641 XML · 5 Java
Objective Detect malware, backdoors, information leaks, obfuscated code, and remote code-download behaviour

1. Executive Summary

The reviewed source code is clean. No malicious code, backdoor, data-exfiltration channel, obfuscated logic, or remote code-download ("dropper") capability was identified.

Beyond the absence of malicious code, the codebase demonstrates deliberate, consistent defensive engineering of a standard appropriate to software that custodies private keys. Several controls found here are ones that trojanised or negligent applications characteristically lack: JavaScript is disabled in WebViews with no JavaScript bridge present at all, certificate validation is left entirely intact, analytics identifiers are cryptographically hashed rather than transmitted raw, and the application manifest actively removes location and microphone permissions that bundled third-party SDKs attempt to introduce.

Ten categories of malicious or leak-prone behaviour were examined. All ten returned negative. Three informational observations are recorded in §5 — none is a vulnerability, and none affects the verdict.

Findings Summary

Severity Count Detail
Critical 0 —
High 0 —
Medium 0 —
Low 0 —
Informational 3 Operational notes for downstream forks (§5)

Verdict

CLEAN. Nothing in the reviewed first-party source behaves maliciously or leaks sensitive data. The security posture is materially better than typical for the category.

Readers should note the scope boundaries in §6 — most importantly that Tangem's own SDKs are consumed as pre-built binary artifacts and were therefore outside the reach of this source review.

Revisions (17 August 2026)

This report was amended after a build of the source was produced and compared against Tangem's official release APK. Three corrections narrow claims that were stated too broadly; one closes a limitation. All should be read before relying on the original text:

Section Change
§3.1 "No native code" holds for the repository, not for the built application, which bundles 14 native libraries — including those performing key derivation, signing, and at-rest encryption
§3.6 The nine permissions listed are the source manifest set. The merged manifest contains 23. "Permissions minimised" overstated the position
O-3 A clean checkout does not build at all — the ds-tokens submodule is unresolvable outside Tangem. The prior text said it compiles
§6.5 Commit provenance is now verified against upstream, closing a limitation rather than adding one

None of these alters the §1 verdict on the source. §3.1 and §3.6 do mean the shipped application has a larger native-code and permission surface than the original report conveyed.

2. Methodology

The review targeted the behaviours that distinguish malicious software from ordinary application code, rather than attempting an exhaustive line-by-line reading of 7,719 files. Each question below was resolved by exhaustive pattern analysis across the full tree, followed by manual reading of every candidate hit in context.

# Question put to the code Result
1 Can it load or execute code obtained at runtime? No
2 Can it execute shell commands or spawn processes? No
3 Does the repository contain native binaries or opaque blobs? No — but the built APK bundles 14 native libraries from binary dependencies; see §3.1
4 Does key material reach logs, storage, or the network? No
5 Does it contact hidden or hostile endpoints? No
6 Are live credentials committed to the repository? No
7 Can the build system pull hostile artifacts? No
8 Does telemetry leak personally identifying data? No — pseudonymised
9 Is transport security weakened anywhere? No — hardened
10 Are permissions over-broad or components exposed? No — minimised

A finding was only cleared once the underlying code was read and understood in context. Two pattern classes produce misleading automated results and are documented explicitly in §4 so that any repeat or automated review does not raise a false alarm.

3. Detailed Findings

3.1 Runtime Code Loading and Dropper Behaviour — CLEAN

No occurrence of DexClassLoader, PathClassLoader, BaseDexClassLoader, InMemoryDexClassLoader, or any dalvik.system API exists in the repository. The application cannot load code it did not ship with.

Process execution. Exactly one match tree-wide:

// app/src/main/java/com/tangem/tap/common/finisher/AndroidAppFinisher.kt:25
Runtime.getRuntime().exit(0)

This terminates the application's own process. It executes nothing.

Native code — repository. No .so libraries, no JNI, and no NDK build inputs are committed to the tree. Only two .jar files exist:

File Size Assessment
gradle/wrapper/gradle-wrapper.jar 55.6 KB Standard Gradle 8.14.1 wrapper
app/libs/dexprotector-annotations.jar 3.5 KB Compile-time annotations only (§3.9)

Native code — built application. (Correction, 17 Aug 2026.) The statement above describes the repository, not the artifact. A build of this source bundles 14 native libraries, several of them security-critical:

libTrustWalletCore.so · libsecp256k1-jni.so · libTrezorCrypto.so · libargon2.so
libblst.so · libsqlcipher.so · libuniffi_yttrium.so · libtoolChecker.so
libtensorflowlite_jni.so · libbarhopper_v3.so · libjnidispatch.so
libimage_processing_util_jni.so · libandroidx.graphics.path.so · libsurface_util_jni.so

Key derivation and signing (libTrustWalletCore, libsecp256k1-jni, libTrezorCrypto), key stretching (libargon2), and at-rest database encryption (libsqlcipher) are all performed in native code. These arrive through the pre-built Maven dependencies excluded from this review by §6.1 and were therefore not examined. Tangem's own release build adds libdexprotector.so and libalice.so on top. See APKANALYSIS.md §4.2.

Reflection. Searches for Class.forName, getDeclaredMethod, getDeclaredField, and setAccessible returned zero genuine results. There is no reflective dispatch to hide behaviour behind.

3.2 Obfuscation and Encoded Payloads — CLEAN

A scan for long opaque literals (≥200 characters of Base64-like text) returned three hits, all in libs/visa/:

  • TangemPaymentAccountRegistry.java
  • TangemBridgeProcessor.java
  • TangemPaymentAccount.java

Each declares public static final String BINARY = "6080604052…". The 6080604052 prefix is the standard EVM (Solidity) contract constructor prologue. These are Web3j-generated smart-contract wrappers carrying on-chain deployment bytecode — an expected artifact of the Visa payment-account integration, not concealed program logic.

All eight Base64.decode call sites serve declared cryptographic purposes — AES/RSA key and IV decoding in RainCryptoUtil, DefaultAuthNonceDecryptor, and SetVisaPinCodeUseCase, plus swap transaction decoding. None reconstructs an executable payload.

3.3 Private Key and Seed Phrase Handling — CLEAN

This is the highest-consequence area for a wallet. It is handled correctly.

Key material never reaches logs. Every logging call (Log.*, Timber.*, println) was cross-referenced against mnemonic, seed, privateKey, passphrase, secret, accessCode, passcode. No true positives. The only matches were UI-state fields on onboarding screens (dialog.dismissButtonText, dialog.dismissWarningColor) — incidental matches on the substring "dismiss", carrying no secret data.

Key material never reaches the network. The sole endpoint whose name suggests otherwise is v1/seedphrase-notification/{wallet_id}. Its complete payload is:

data class SeedPhraseNotificationDTO(val status: Status)

enum class Status { NOT_NEEDED, NOTIFIED, DECLINED, CONFIRMED, REJECTED, ACCEPTED }

A single enum recording whether the user was reminded to back up their phrase. No phrase material is transmitted.

Export is authentication-gated. ExportSeedPhraseUseCase delegates to DefaultHotWalletAccessor.exportSeedPhrase(), which routes through hotSdkRequest() — a path requiring password or biometric unlock (HotAuth.Password / HotAuth.Biometry) before the SDK releases the mnemonic. Wrong-password retry and biometric lockout are handled explicitly.

Exported phrases have exactly two consumers, both user-initiated display flows:

  • features/hot-wallet/impl/…/viewphrase/model/ViewPhraseModel.kt — user views their own backup
  • features/onboarding-v2/impl/…/upgradewallet/model/MultiWalletUpgradeWalletModel.kt

Neither transmits, persists, nor logs the value.

Supporting controls. clearContextualUnlock() and clearAllContextualUnlock() purge unlocked wallet handles from memory; LockUserWalletsTimer auto-locks wallets on a timer via WorkManager.

3.4 Network Endpoints — CLEAN

Every hardcoded host in the tree was enumerated and classified. All fall into legitimate categories:

Category Examples
Public blockchain RPC Ankr, publicnode, dRPC, thirdweb, Infura, QuikNode, GetBlock, Arbitrum, Base, Solana, Tron, Kaspa, Polkadot
Tangem infrastructure api.tangem.com, express.tangem.com, buy.tangem.com
Payment / staking partners MoonPay, Mercuryo, P2P.org, StakeKit, Paera
Documentation / schema schemas.android.com, developer.android.com, EIP references

No unexplained endpoint, dead-drop host, dynamic-DNS domain, or hardcoded IP address was found.

3.5 Transport Security — HARDENED

app/src/main/res/xml/network_security_config.xml:

<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>
  • Cleartext HTTP disabled application-wide.
  • System trust anchors only — user-installed CAs are excluded, resisting casual interception proxies.
  • No debug-overrides block.

Searches for X509TrustManager, checkServerTrusted, HostnameVerifier, ALLOW_ALL, and SSLContext returned zero results. No certificate-validation bypass exists anywhere in the repository — a common weakness that is simply absent here.

WebView. core/ui/…/webview/WebViewExt.kt sets javaScriptEnabled = false. There is no addJavascriptInterface or @JavascriptInterface anywhere in the tree. The JavaScript-bridge attack surface does not exist by construction.

3.6 Permissions and Exported Components — RESTRAINED IN SOURCE, WIDER AS SHIPPED

Permission set declared in the hand-written manifests (app/src/main/, app/src/huawei/):

INTERNET · ACCESS_NETWORK_STATE · CAMERA (QR scanning) · NFC (card scanning) · USE_BIOMETRIC · VIBRATE · WAKE_LOCK · HIDE_OVERLAY_WINDOWS · AD_ID

Nothing there exceeds what a wallet requires.

Correction (17 Aug 2026). An earlier revision presented the nine above as the complete set and listed external storage and RECEIVE_BOOT_COMPLETED among permissions that were absent. That was wrong. The nine describe the source manifests; the merged manifest in the built APK contains 23. The additional fourteen, contributed by manifest merging from bundled third-party SDKs:

READ_EXTERNAL_STORAGE · WRITE_EXTERNAL_STORAGE · WRITE_SETTINGS
RECEIVE_BOOT_COMPLETED · FOREGROUND_SERVICE · USE_FINGERPRINT · POST_NOTIFICATIONS
BIND_GET_INSTALL_REFERRER_SERVICE · ACCESS_ADSERVICES_ATTRIBUTION
ACCESS_ADSERVICES_AD_ID · c2dm.RECEIVE · DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
com.samsung.android.mapsagent.permission.READ_APP_INFO
com.huawei.appmarket.service.commondata.permission.GET_COMMON_DATA

WRITE_SETTINGS and RECEIVE_BOOT_COMPLETED are broader than a wallet needs and are not explained by first-party code; they warrant enquiry with the SDK vendors that introduce them. This merged set is identical in Tangem's official release APK and in a build from this source — see APKANALYSIS.md §4.1 and D-1.

Still genuinely absent from the merged manifest: SMS, contacts, call log, location, microphone, accessibility services, SYSTEM_ALERT_WINDOW, and REQUEST_INSTALL_PACKAGES.

Two measures are worth drawing out, as both are affirmative hardening rather than mere restraint:

1. Overlay defence. HIDE_OVERLAY_WINDOWS is requested to defeat tapjacking — a known vector for hijacking wallet transaction-confirmation dialogs.

2. Permission stripping. The manifest actively removes permissions that bundled third-party SDKs would otherwise introduce through manifest merging:

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"   tools:node="remove" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" tools:node="remove" />
<uses-permission android:name="android.permission.RECORD_AUDIO"           tools:node="remove" />

Denying location and microphone access to advertising and analytics SDKs is a privacy measure that argues directly against hostile intent. This control was verified in the shipped artifact: neither location nor RECORD_AUDIO appears in the merged manifest of Tangem's official release APK (APKANALYSIS.md §4.1). The stripping is effective, not merely declared.

Exported components. Exactly one: MainActivity, necessarily exported as the launcher. Its intent filters are tightly scoped — the LAUNCHER category, NFC NDEF discovery restricted to tangem.com / www.tangem.com / app.tangem.com under /ndef path prefixes, and the wc: and tangem://wc WalletConnect schemes.

The single declared service, TangemPushNotificationService (Firebase Cloud Messaging), is exported="false". There are no broadcast receivers, no boot receivers, and no content providers. The only WorkManager job in the application is LockUserWalletsTimer — which locks wallets.

3.7 Telemetry and Personal Data — CLEAN (pseudonymised)

Analytics and marketing SDKs present: Firebase Analytics/Crashlytics, Amplitude, AppsFlyer, CustomerIO, SurveySparrow. This is conventional commercial telemetry, declared openly in the build configuration.

The user identifier transmitted to these services is hashed, never raw (app/…/analytics/DefaultTrackingContextProxy.kt):

private fun calculateUserIdHash(userWalletId: UserWalletId?): String? {
    return userWalletId?.value
        ?.calculateSha256()
        ?.toHexString()
}

Every setUserProperties call site — cold wallet, hot wallet, and scan response — routes through this function. Accompanying properties are non-identifying product facts (batchId, productType, firmwareVersion).

No device-identifier harvesting was found in any analytics path: no Settings.Secure.ANDROID_ID, no IMEI, no MAC address, no subscriber ID.

3.8 Local Diagnostic Logging — CLEAN

NetworkLogsSaveInterceptor records HTTP traffic to a local AppLogsStore, supporting the in-app "contact support with logs" feature. The implementation shows care:

  • URLs pass through SensitiveUrlMasker, replacing configured secrets with ******. The masker sorts candidates by descending length, so a shorter value that is a prefix of a longer one cannot mask first and leave a partial secret exposed — a considered detail.
  • Sensitive endpoints are excluded from body logging entirely, via restrictedForLogURLs (api.stakek.it/v1/yields/enabled) and restrictedForLogHosts (us.paera.com).
  • Response bodies beyond ~2 MB are skipped; binary bodies are omitted.

Egress is user-initiated only. DefaultFeedbackRepository exposes getLogFile() / getZipLogFile() and passes the file to EmailSender as an attachment, opening the platform email intent. Logs are never uploaded automatically or silently. See Observation O-1.

3.9 Build System and Supply Chain — CLEAN

Repositories — all official, no typosquats or unexpected mirrors:

gradlePluginPortal() · google() (content-filtered to androidx / com.android / com.google) · mavenCentral() · developer.huawei.com/repo (official, for the Huawei flavour) · maven.pkg.github.com/tangem/* (first-party)

settings.gradle.kts enforces:

repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

This prevents any individual module from silently introducing its own repository — a meaningful supply-chain control, and one many projects omit.

No build-time code execution or fetching. All *.gradle.kts and *.gradle files were searched for exec {, URL(, download, curl, wget, and HttpURLConnection. Zero results. The build does not download or run anything beyond declared Maven dependencies.

Gradle wrapper — distributionUrl resolves to the official https://services.gradle.org/distributions/gradle-8.14.1-bin.zip.

gradle-wrapper.jar   SHA-256: 3dc39ad650d40f6c029bd8ff605c6d95865d657dbfdeacdb079db0ddfffedf9f
                     Size:    55,616 bytes

Verify this against the official Gradle 8.14.1 wrapper when reproducing the build.

DexProtector. The com.dexprotector.rtc.RtcStatus reference in DefaultDeviceSecurityInfoProvider is Licel's commercial application-hardening product, integrated for runtime root, emulator, and tamper detection. Its presence is a defensive control, not concealment: the mock build flavour transparently substitutes MockAwareDeviceSecurityInfoProvider, which reports a clean device.

3.10 Committed Credentials — CLEAN

app/src/main/assets/tangem-app-config/config_prod.json and config_dev.json declare the full key schema — Amplitude, AppsFlyer, Blockchair, BlockCypher, Infura, QuikNode, GetBlock, MoonPay, Mercuryo, NowNodes, TonCenter and others — with every value set to the literal string PLACEHOLDER. No live credentials are committed.

The only committed keystore is a dummy debug keystore:

store_password=android
key_alias=dummy
key_password=android

These are the well-known Android debug defaults. The keystore cannot sign a release build. See Observation O-3.

4. Expected False Positives

Two pattern classes in this repository will alarm automated scanners and reviewers working from grep output alone. Both are benign. They are documented here so that any subsequent review reaches the same conclusion without re-investigating.

FP-1 — loadDex* is Decentralised Exchange, not Android DEX

A search for loadDex returns numerous hits across features/swap/:

loadDexSwapData · loadDexSwapDataNoFee · loadDexSwapFee · DexSwapFeeCalculator · ResolvedFlow.DexLike

DEX here means Decentralised EXchange — token-swap business logic. These functions load swap quotes and fee data from exchange providers. They have no relationship to Android DEX bytecode or class loading. Confirmed by reading SwapInteractorImpl.kt and the surrounding swap domain.

FP-2 — Hostile hostnames are security test fixtures

The following appear as string literals in the tree:

faketangem.com · fake.tangem.com · tangem.com.attacker.com
buy.tangem.com.attacker.com · evil-spoofed.example · fake.surveysparrow.com

Every one is a negative test case asserting expected = false, located in:

  • common/src/testDebug/…/uri/ExternalUrlValidatorTest.kt
  • data/wallet-connect/src/test/…/DefaultWcPairUseCaseTest.kt

Their presence is evidence of a deliberate anti-spoofing URL validator and a WalletConnect proposal-spoofing defence, verified against realistic attack strings. These are security controls under test, not indicators of compromise.

5. Observations

Operational notes for anyone forking or deploying this application. None is a vulnerability, and none affects the verdict in §1.

O-1 — Support logs are financially sensitive

When diagnostic logging is active, full JSON request and response bodies are written to local application storage. URLs are masked and specific hosts excluded (§3.8), but bodies may still contain wallet addresses, balances, and transaction details. The data never leaves the device unless the user deliberately emails it to support.

Recommendation: treat a user-submitted support-log attachment as sensitive financial data in your support process — restrict access, and set a retention limit.

O-2 — Third-party telemetry ships enabled by default

Five analytics and marketing SDKs (Firebase, Amplitude, AppsFlyer, CustomerIO, SurveySparrow) and the AD_ID permission are present in the Google flavour. This is disclosed and the user identifier is pseudonymised (§3.7).

Recommendation: a privacy-focused fork may wish to remove Amplitude, AppsFlyer, CustomerIO, and SurveySparrow, and drop the AD_ID permission. The Huawei flavour already differs in SDK composition.

O-3 — A clean checkout does not build, and does not fully function once it does

(Revised 17 Aug 2026 after an actual build was attempted. The previous text stated a clean checkout compiles; it does not.)

The build fails outright. core/ui/ds-tokens is registered in the tree as a submodule gitlink (commit a59c6a36), but no .gitmodules file exists anywhere in the repository's 16,087-commit history. There is no URL from which the submodule can be resolved. :core:ui:verifyDesignTokens runs during preBuild and aborts before any module compiles, emitting the instruction git submodule update --init --recursive — which cannot succeed outside Tangem's own environment.

The task only verifies: it hashes the submodule's JSON and SVG sources and compares the digest against a committed .tokens-hash. It generates nothing, and the 380 generated files it guards are all committed. Building with -x :core:ui:verifyDesignTokens therefore produces a functionally complete APK, at the cost of losing the assurance that the committed generated sources still correspond to the design tokens they derive from.

Once building, integrations remain partly inert. All configuration values are PLACEHOLDER (§3.10) and are compiled into the APK at build time by GenerateEnvironmentConfigTask. No runtime check detects the sentinel, so the application transmits PLACEHOLDER as a live credential and receives authentication failures.

The practical effect is uneven. providers_order.json lists RPC providers per chain as either public (no key) or private (keyed), and the SDK falls through the list in order. Of 97 chains, 87 retain at least one public provider and will synchronise without any key. The 10 that do not are:

bitcoin · ethereum · solana · cardano · litecoin
dogecoin · bitcoin-cash · dash · the-open-network · chia

— that is, the chains most users actually hold. Fiat prices and the swap aggregator additionally depend on Tangem-issued credentials that cannot be self-provisioned.

Consequence for downstream forks: a PLACEHOLDER build presents as a working wallet while silently failing to report balances on the major chains. A user scanning a funded card may see a zero balance and conclude their funds are lost. Such a build should not be distributed to non-technical users, and any release of one should say so explicitly.

Publishing a source tree without private keys or internal submodules is correct practice, not a defect — but the resulting checkout is neither buildable nor safely usable as-is, and that should be stated plainly rather than left to be discovered.

6. Scope and Limitations

These boundaries are stated plainly so that no broader assurance is inferred than was actually obtained.

  1. First-party source only. Tangem's own SDKs — com.tangem:blockchain (Blockchain SDK), tangem-sdk-kotlin (Card SDK), tangem-hot-sdk-kotlin (Hot Wallet SDK), wallet-core, vico, and web3j — are resolved as pre-built binary artifacts from GitHub Packages at build time and were not reviewed. This is a material limitation: the hot-wallet SDK performs the actual mnemonic encryption and at-rest storage. Assurance over those components requires a separate review of their own repositories.

  2. Third-party Maven dependencies were not individually reviewed, although the repository set from which they are drawn is constrained and official (§3.9).

  3. No dynamic analysis was performed. This is a static review. No APK was executed, instrumented, decompiled, or observed on a network. Runtime behaviour was inferred from source.

  4. No cryptographic correctness review. This review establishes that key material is not leaked. It does not assess whether the encryption schemes protecting that material at rest are correctly chosen or parameterised.

  5. Commit provenance — resolved. (Updated 17 Aug 2026.) An earlier revision recorded this as an open limitation. It has since been closed: git ls-remote confirms that master at github.com/tangem/tangem-app-android is 358144ee61a9f65e0f39578e8c943226abb5d996 — the exact commit reviewed — and git diff against it is empty. The reviewed tree is the published upstream tree, unmodified.

    The Updated on 2026-08-14 subject line appears on all 16,087 commits, not merely recent ones, so it is an artefact of how the upstream repository is published rather than evidence of rewriting. Per-change authorship and history remain unavailable for inspection, so the content of individual upstream changes could not be reviewed; the identity of the tree is now established.

  6. Point-in-time. Findings apply to commit 358144ee61a only.

7. Conclusion

The reviewed source is clean. No malware, backdoor, dropper, exfiltration channel, or intentionally obfuscated logic was identified across ten categories of examination.

The codebase further exhibits positive security engineering that would be unusual in a trojanised or negligent application:

  • JavaScript disabled in WebViews, with no JavaScript bridge present at all
  • Certificate validation fully intact; cleartext traffic disabled; user-installed CAs excluded
  • Location and microphone permissions actively stripped from third-party SDK manifests
  • Analytics identifiers SHA-256 hashed rather than transmitted raw
  • A dedicated external-URL anti-spoofing validator, tested against realistic attack strings
  • Tapjacking/overlay protection via HIDE_OVERLAY_WINDOWS
  • Seed-phrase export gated behind biometric or password authentication
  • Automatic wallet locking on an inactivity timer
  • FAIL_ON_PROJECT_REPOS constraining the build supply chain
  • Commercial runtime tamper and root detection

Subject to the scope boundaries in §6 — in particular the unreviewed binary SDKs and the native libraries they contribute (§3.1) — nothing in the reviewed first-party source is an obstacle to building and distributing this application.

That is a narrower statement than "safe to distribute", and deliberately so. A build produced from this source alone carries PLACEHOLDER credentials and will not report balances on the ten most widely held chains while otherwise presenting as a functioning wallet (O-3). Anyone distributing such a build must say so explicitly. Assurance over the binary that Tangem itself ships is a separate question, addressed — and largely left open — in APKANALYSIS.md.

Static source review of commit 358144ee61a. Findings reflect that commit only; re-audit after merging upstream changes.