Gumawa o i-unlock muna ang Vault gamit ang master password nito. Buksan ang Settings → Security, suriin ang status ng provider at i-enable ang biometric na pag-unlock. Humihingi ang enrollment ng bagong authentication ng sistema. Pagkatapos nito, nag-aalok ang login overlay ng pag-unlock gamit ang Touch ID, Windows Hello o fingerprint sa tabi ng form ng master password. Inaalis ng Disable and remove enrollment ang naka-cache na key ng application na ito, hindi kailanman ang mga fingerprint na nakarehistro sa operating system.
Panatilihin ang master password: nangangailangan ng fallback sa password ang pagkansela, timeout, hindi available na hardware/keyring at hindi na wastong enrollment. Lokal lamang sa user, device at Vault na ito ang biometric enrollment. Hindi ito mekanismo ng recovery o backup. Ang pag-reset sa Vault ay nagbabawi sa enrollment at nagbubura sa mga umiiral na naka-encrypt na profile at host fingerprint pagkatapos lamang ng umiiral na kumpirmasyong SMAZAT.
| Platform | Authentication at storage | Mga kinakailangan at limitasyon |
|---|---|---|
| macOS Apple Silicon | Native na LocalAuthentication / Touch ID; Keychain item ng Security.framework na may biometryCurrentSet at WhenUnlockedThisDeviceOnly |
Naka-enroll na Touch ID, available na sensor at magagamit na login Keychain. Ginagawang hindi wasto ng mga pagbabago sa fingerprint ang item. Gumamit ng stable na Developer ID signing para sa mga production update; maaaring makagambala ang ad hoc na alpha signing sa tiwala ng Keychain at sa pagsubaybay sa pahintulot sa local network. |
| Windows x64 | Native na WinRT Windows Hello desktop interop na naka-attach sa pangunahing HWND; key na naka-encrypt gamit ang DPAPI ng kasalukuyang user sa Windows Credential Manager | Naka-configure na Hello fingerprint, mukha o PIN. Isa itong convenience unlock: ipinapatupad ng app ang pag-apruba ng Hello, habang ang DPAPI mismo ay hindi protektado ng biometrics. Maaaring i-decrypt ang kredensyal ng ibang code na tumatakbo bilang parehong user. |
| Ubuntu x64 | Naka-enroll na fingerprint ng kasalukuyang user sa pamamagitan ng fprintd D-Bus; tahasang pag-iimbak ng kredensyal sa libsecret / Secret Service | Sinusuportahang reader, naka-enroll na fingerprint, tumatakbong desktop Secret Service at default na keyring. Convenience unlock: hindi kriptograpikong nakatali sa pag-verify ng fingerprint ang kredensyal sa keyring. Walang fallback sa basic_text o plaintext file. |
Sa Ubuntu, ang mga opsyonal na runtime package ay python3-gi, gir1.2-secret-1, gnome-keyring (o ibang compatible na Secret Service) at fprintd. I-install ang mga nawawalang package gamit ang karaniwang package manager ng OS, pagkatapos ay mag-enroll ng fingerprint sa mga setting ng OS. Ginagamit ng authentication ang kasalukuyang user at hindi ito nangangailangan ng root o nagbabago ng PAM. Nag-uulat na hindi available ang headless na SSH session na walang desktop keyring; hindi ito tahimik na nag-iimbak ng key sa ibang lugar.
Mga patakaran sa pag-lock
Naka-off ang awtomatikong pag-lock para sa mga umiiral na installation. Kapag in-enable, 15 minuto ang default; ang mga sinusuportahang value ay Never, 1, 5, 10, 15, 30 at 60 minuto. Itinuturing na aktibidad ang input ng keyboard at mouse sa mga window ng application; hindi ang papasok na SSH output. Itinuturing ng opsyonal na focus locking ang mga plugin window ng application bilang bahagi ng app at pinapayagang matapos ang kasalukuyang prompt ng authentication ng sistema. Nangangailangan ng master password ang pagbabago sa mga patakarang ito.
Ang bawat pag-lock ng Vault, kasama ang pag-lock dahil sa kawalan ng aktibidad at pagkawala ng focus, ay nagdidiskonekta sa mga aktibong SSH session, nagsasara ng mga plugin at nagtitigil sa diagnostiko. I-save ang mga remote na pag-edit bago mag-lock. Pinapanatili nito ang umiiral na gawi ng manwal na pag-lock; walang SSH credential na nananatiling available sa mga background plugin pagkatapos ng pag-lock.
Humihingi ang opsyonal na patakaran para sa sensitibong operasyon ng bagong authentication ng sistema para sa pagbura ng profile, pag-install/pag-alis ng plugin, paglulunsad ng installer at pag-reset ng naka-unlock na Vault. Nasa labas ng patakarang ito ang mga remote na terminal command at mga pag-edit ng file ng plugin. Hindi pinapalitan ng patakaran ang awtorisasyon ng SSH server. Kung huminto sa paggana ang provider, mag-unlock gamit ang master password at baguhin ang patakaran gamit ang password na iyon. Nananatiling available ang reset mula sa naka-lock na recovery screen pagkatapos ng mapanirang kumpirmasyon nito.
Disenyo ng Vault at IPC
Nananatiling AES-256-GCM na may scrypt ang umiiral na v1 Vault; hindi muling isinusulat ng enrollment ang mga file nito o binabago ang schema nito. Isang kopya lamang ng hinangong 32-byte na key nito ang napupunta sa credential storage ng OS. Hindi kailanman iniimbak ang plaintext na master password. Naglalaman ang lokal na enrollment metadata ng random na credential ID, provider at SHA-256 binding sa hindi nababagong metadata ng Vault. Dapat pumasa sa authenticated decryption ang na-recover na key bago magbukas ng session. Nililinis ang mga buffer ng pangunahing proseso pagkatapos gamitin; pansamantalang memory ng proseso ang mga native protocol string, hindi pag-angkin ng kumpletong pagbura ng memory sa mga managed runtime.
Nakikipag-ugnayan ang helper sa pamamagitan ng limitado at pribadong stdin/stdout pipe, hindi tumatanggap ng mga shell command, may mga authentication timeout at nagbabalik ng nilinis na mga error code. Naka-package ang mga helper sa labas ng ASAR sa resources/biometrics; mga hiwalay na native executable ang mga ito, kaya walang kinakailangang Electron ABI native module. Gumagamit ang Linux helper ng Python at GI ng sistema. Hindi kailanman tumatawid sa renderer/plugin bridge ang mga native object at hinangong key. Bine-validate ng biometric IPC ang live na pangunahing window at ang main frame nito; hindi ito matatawag ng mga plugin. Kinakansela ng tahasang pag-lock ang nakabinbing biometric at password unlock para hindi mabuksan muli ng huling pag-apruba ang Vault. Binabawi ng pag-alis ng enrollment ang lokal na binding nito kahit offline ang OS store; maaaring manatili sa hindi maabot na store ang hindi na magagamit na naulilang kredensyal.
Build at pag-verify
Inihahanda ng npm run biometrics:build ang helper para sa host platform; awtomatiko itong tinatawag ng development start at ng paghahanda ng release. Nangangailangan ang macOS ng Swift/Apple SDK na may Security at LocalAuthentication; nangangailangan ang Windows ng Visual Studio C++ Build Tools, Windows SDK at C++/WinRT; kinokopya ng Linux ang Python helper. Walang idinagdag na bagong npm dependency. Mag-build nang native sa bawat target na OS. Kasama ang macOS helper sa recursive na bundle signing; hindi nito kailangan ng App Sandbox entitlement dahil hindi naka-sandbox ang desktop app na ito. Nangangailangan pa rin ang production na pamamahagi sa macOS ng Developer ID signing at notarization, hiwalay sa mga OpenPGP release signature.
Patakbuhin ang npm test, npm run test:biometrics:ui at npm run test:diagnostics:ui. Gumagamit ang mga biometric Node test at ang hiwalay na UI smoke test ng mock na OS adapter para saklawin ang tagumpay, pagtanggi/pagkansela, maling key, nawawalang hardware/enrollment, reset, timeout at huling resulta, hindi available na Linux keyring, pagkabigo ng kredensyal ng OS, mga tugon ng Windows na inaprubahan gamit ang PIN, mga pagbabago sa enrollment sa macOS, compatibility sa umiiral na Vault, IPC isolation at paglilinis ng SSH. Hindi nito pinatutunayan ang matagumpay na authentication sa hardware.
Na-verify ang native compilation sa macOS arm64 at Windows x64. Nag-uulat ang macOS na available ang Touch ID; nag-uulat ang Windows VM na hindi available ang Hello. Nangangailangan pa rin ng interactive na pagsubok sa hardware sa bawat sinusuportahang sistema ang enrollment ng fingerprint/mukha/PIN, aktwal na pagkuha ng protektadong key, pagkansela ng dialog ng OS at pag-invalidate dahil sa pagbabago ng enrollment. Dapat ding subukan ang Linux helper sa isang desktop na may sinusuportahang fprintd reader; hindi mapatutunayan ng headless VM ang pag-verify na iyon.
Mga sanggunian sa platform: Biometric access control ng Apple, Windows desktop Hello interop, Lifecycle ng device sa fprintd, Espesipikasyon ng Secret Service.
Access sa local network para sa SSH sa macOS
Kung nabibigo ang bawat lokal na SSH profile na may connect EHOSTUNREACH pero gumagana ang parehong koneksyon sa Terminal, suriin ang System Settings → Privacy & Security → Local Network → CH-J Server Manager, payagan ang access, ganap na isara ang app at buksan itong muli. Kung naka-enable na, i-toggle ang pahintulot nito at mag-restart. Suriin din ang routing, Wi-Fi/Ethernet at VPN: hindi patunay ng pagtanggi sa privacy ang error na ito lamang. Huwag i-reset ang Vault o itapon ang mga pinagkakatiwalaang SSH fingerprint dahil sa error na ito.
Idinedeklara ng app ang NSLocalNetworkUsageDescription at nagbibigay ng naka-localize na gabay para sa mga error sa pahintulot/ruta ng network sa macOS. Hindi nito kayang bigyan ang sarili ng pahintulot. Inirerekomenda ng Apple ang signing identity na inisyu ng Apple para maaasahang masubaybayan ng macOS ang network privacy sa iba't ibang build; may limitasyong iyon pa rin ang kasalukuyang ad hoc na mga alpha build. Tingnan ang gabay ng Apple tungkol sa privacy ng local network.
Icon ng application sa Ubuntu
Ini-install ng mga Debian package ang umiiral na icon ng CH-J sa karaniwang mga laki ng hicolor (16–512 px), kasama ang katugmang desktop entry at Electron window class. Natatanggap din ng pangunahing window ang icon kapag ginawa itong muli. Pagkatapos i-update ang dati nang naka-pin na lumang launcher, i-unpin ito at i-pin ang bagong naka-install na application; maaaring i-refresh ng pag-logout/pag-login sa desktop ang lumang cache ng GNOME launcher.