WatchMemory 0.2.0'da kalıntı kararları ve lisans kontrolü

1. Dokümante CI canary tarifi her seferinde FAIL veriyordu

Ne oldu

CI rehberi, README ve GitHub Actions örneği canary'yi uygulamaya launch argument olarak veriyordu (-WMCanary WMCANARY_…). Launch argument'ler süreç ömrü boyunca bellekte kalır; bu yüzden canary logout sonrası her zaman bulunuyordu.

Etkisi

Uygulama logout'ta ne yaparsa yapsın her çalıştırmada yanlış FAIL. Tarifi izleyen ekipler hiçbir zaman geçen bir kapı göremiyordu; bu da kontrolün kapatılmasına davetiye çıkarır.

Ne değişti (Düzeltildiği sürüm 0.2.1)

• Uygulama, -WMCanaryMode 1 (veya SIMCTL_CHILD_WM_CANARY_MODE=1) ile başlatıldığında canary'yi kendisi üretir: WatchMemoryDebugAgent'taki WatchMemory.canaryIfRequested() çağrılır. canaryFromLaunchArguments() kullanımdan kaldırıldı (deprecated).
• Launch argument'lerinde veya ortam değişkenlerinde WMCANARY_ geçen bir süreç taranmak istendiğinde tarama, kalıntı raporlamak yerine çıkış kodu 2 ile durur ve nedenini açıklar.
• Tarif SIMCTL_CHILD_MallocScribble=1 ve SIMCTL_CHILD_MallocNanoZone=0 ayarlar; böylece serbest bırakılan native bellek üzerine yazılır ve kalıntı sayılmaz.
• CI rehberi, README ve örnekler düzeltildi.

2. Uygulama depolamasındaki opak refresh token'lar yanlış PASS üretebiliyordu

Ne oldu

Tanınabilir biçimi olmayan token'lar (örneğin JWT'den farklı olarak opak bir rt_… refresh token) birkaç depolama biçiminde bulunamıyordu: UserDefaults plist'leri, SQLite anahtar/değer satırları, AsyncStorage içindeki redux-persist verisi ve MMKV dosyaları. Genel bir key=value kuralı bulduğunda ise Orta (Medium) sayılıyor, varsayılan eşiğin (High) altında kalıyordu.

Etkisi

Logout sonrası diskte kalan bir refresh token PASS ile sonuçlanabiliyordu. Bu yalnızca kararın doğruluğunu etkiler; WatchMemory token'ı kimseye açmadı.

Ne değişti (Düzeltildiği sürüm 0.2.1 (önem derecesi), 0.3.0 (tespit))

• 0.2.1: refresh, access, ID, session veya auth token anahtarı altında bulunan değerler High sayılır ve varsayılan eşikte kapıyı kırar. SQLite write-ahead log (-wal) dosyaları da okunur.
• 0.3.0: plist, SQLite, JSON (AsyncStorage ve redux-persist dahil), XML preferences, MMKV ve DataStore'dan anahtar bilgisiyle çıkarım; tam depo ve anahtar adını verir, örneğin SDK:redux-persist › persist:root › auth › refreshToken (AsyncStorage'daki redux-persist).
• 0.3.0: residue capture --track-from BEFORE.json, logout öncesi görülen sırları logout sonrası depolama ve dosyalarda değerleriyle yeniden arar; hiçbir kalıp eşleşmese bile (yazıldığı gibi; base64 gibi yeniden kodlanmış kopyalar izlenmez). Yalnızca anahtarlı hash'ler saklanır, değerler asla.
• Sınır: yalnızca bellekte kalan opak bir değer henüz takip edilmiyor (0.4 için planlandı).

3. Lisans doğrulaması başka mağazaların anahtarlarını kabul ediyordu

Ne oldu

Lemon Squeezy mağaza ve ürün kimliklerinin yapılandırılmadığı build'lerde lisans doğrulaması başka bir Lemon Squeezy mağazasının verdiği bir anahtarı kabul edebiliyordu.

Etkisi

Pro özellikleri WatchMemory satın alınmadan açılabiliyordu. Tarama verisi ve sonuçlar etkilenmedi.

Ne değişti (Düzeltildiği sürüm 0.2.1)

• Release build'ler WatchMemory mağaza ve ürün kimliklerini içerir; eksiklerse doğrulama kapalı kalır (fail closed).
• Başka mağazalardan kalan önbellekteki doğrulamalar güncellemede silinir; bunlara çevrimdışı tolerans tanınmaz.
• watchmemory.app üzerinden alınan anahtarlar çalışmaya devam eder. Güncellemeden sonra anahtarınız çalışmazsa support@watchmemory.app adresine yazın.

Ne yapmalısınız

1. Mac uygulamasını indirme sayfasından veya uygulama içi güncelleme bandından 0.3.0'a güncelleyin.

2. CI'da sürümsüz tarball'ı doğrudan tar'a vermeyi bırakın. Sürümlü CLI'ı indirin, SHA-256 değerini sabitlediğiniz değerle karşılaştırın, sonra açın.

   V=0.3.0
   curl -fsSLO https://watchmemory.app/downloads/watchmemory-cli-$V.tar.gz
   # pin the SHA-256 from the release notes in your pipeline, then:
   echo "$WM_CLI_SHA256  watchmemory-cli-$V.tar.gz" | shasum -a 256 -c -
   tar xzf watchmemory-cli-$V.tar.gz

3. -WMCanary WMCANARY_… launch argument'lerini canary modu tarifiyle değiştirin; canary'yi uygulama üretsin.

   SIMCTL_CHILD_WM_CANARY_MODE=1 SIMCTL_CHILD_MallocScribble=1 SIMCTL_CHILD_MallocNanoZone=0 \
     xcrun simctl launch booted com.acme.app
   
   // in the app (WatchMemoryDebugAgent, DEBUG builds only)
   let token = WatchMemory.canaryIfRequested("access_token") ?? realToken

4. 0.2.0 ile geçmiş her kalıntı kontrolünü veya CI kapısını yeniden çalıştırın; özellikle uygulamanız refresh token'ı UserDefaults, AsyncStorage, MMKV veya SQLite'ta tutuyorsa. İki tarafı da 0.3.0 ile yeniden kaydedin: 0.2.x kaydını 0.3.0 kaydıyla karşılaştırmak reddedilir.

   watchmemory residue capture --process MyApp --bundle-id com.acme.app --out before.json
   # log out
   watchmemory residue capture --process MyApp --bundle-id com.acme.app \
     --track-from before.json --out after.json
   watchmemory residue compare before.json after.json --html residue.html

5. Mevcut baseline'lar okunmaya devam eder. Sır bazlı eşleştirmeye geçmek için 0.3.0 ile yeniden kaydedin.

Zaman çizelgesi

• 2026-10-15: sorunlar 0.2.0'ın iç güvenlik ve kalite incelemesinde bulundu.
• 0.2.1: üç sorun için önlemler.
• 0.3.0: anahtar bilgisiyle depolama çıkarımı ve önce/sonra değer takibi (2. sorun).

Bulan: WatchMemory'nin iç incelemesinde bulundu.

Sorular: security@watchmemory.app adresine yazın. /tr/security