• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    SPIRALIRust - Programovací jazyk
    SHINING_KATE
    SHINING_KATE --- ---
    2 odpovědi+1
    DATEL: Rocket je dost známý, jediný problém byl, že po většinu své existence vyžadoval nightly verzi Rustu kvůli featurám, které ještě ve stable vydání nebyly. Používat to v produkci byl z mé zkušenosti docela hazard, každou chvilku se něco rozbilo.

    Aktuální vývojové verze (0.5.0-dev) by měly být funkční ve stable rustu a async.
    Mimochodem, podle všeho je v Rocketu napsaný Nyx ;)

    Naše firma ovšem dala přednost actix.rs a píšem v tom všechno.

    Co se týče GUI knihoven, přímou zkušenost nemám, ale věcí co jsou postavené na GTK-rs je docela dost a lidi kolem GNOME na Rust zdá se celkem sází, navíc je docela oblíbený https://github.com/hecrj/iced (tam je super i možnost kompilace do webassembly)
    DATEL
    DATEL --- ---
    3 odpovědi+2
    Kolega mi zmínil webový Rustový framework, zkoušel ho a prý se mu docela líbí, můžete dát na nástěnku třeba :)
    Rocket - Simple, Fast, Type-Safe Web Framework for Rust
    https://rocket.rs

    Letmo jsem zkusil kouknout na nějaké GUI knihovny, asi bude něco kolem GTK, nemáte někdo osobní zkušenost s něčím?
    WILD_A
    WILD_A --- ---
    SHINING_KATE: Zatim jsem neprepinal default tj rust-analyzer ale muzu zkusit.
    SHINING_KATE
    SHINING_KATE --- ---
    1 odpověď
    WILD_A: Nejsem emacs user, ale co https://emacs-lsp.github.io/lsp-mode/page/lsp-rust/ ?
    WILD_A
    WILD_A --- ---
    1 odpověď+1
    Ja mam emacs na vsecno, takze emacs + rust-mode + rustic. Pokud nejste emacs user vrele nedoporucuji.
    SHINING_KATE
    SHINING_KATE --- ---
    +1
    MARASAN: Mám to jako Spirali. A https://tracing.rs/tracing/ je neskutečně mocný nástroj :)
    SPIRALI
    SPIRALI --- ---
    MARASAN: Ja pouzivam spise nez interaktivni debugger tak intenzivni logovani a trasovani. Z trasovani pak delame taky performance analyzu. To doplnujeme standardnimi C/C++ nastroji. Ja mam rad callgrind; kolega, ktery je v tom kovany tak jeho nejoblibenejsi tool pro toto je VTune.
    SPIRALI
    SPIRALI --- ---
    NYX: Nevim jestli rozbiti na vice crate az tolik pomuze. Pro pri vyvoji vice crate najednou stejne chce clovek workspace a zase tam bude jen jeden cargo lock. Alespon me nejaka takova kolize trapila davno s nejakou tehdejsi verzi RLS a vice crate mi moc nepomohlo.
    MARASAN
    MARASAN --- ---
    2 odpovědi
    co vy a debugger? profiler? VS Code je v tomhle ohledu komfortni nebo ne? pro linux.
    SHINING_KATE
    SHINING_KATE --- ---
    SPIRALI: CLion + rust plugin. V teamu to momentálně máme 2x CLion, 2x VSCode + RA a 1x Atom jen se základním Rust pluginem bez autocomplete.
    NYX
    NYX --- ---
    1 odpověď
    SPIRALI: No rust-analyzer mam vypnuty, nejak mi to kolidovalo s buildem (vyrobil ten cargo lock a build na nej pak ceka). To pouzivam jako pomerne tupy editor :) Takze asi nejsem schopny odpovedet.

    Kdyz me to bude dlouhodobe stvat, dam si tu praci a rozbiju to na vic nezavislych crate. Nemelo by to byt moc slozite.
    MARASAN
    MARASAN --- ---
    SPIRALI: pouzivam vim s nejakyma pluginama, ale uvazuju, ze zkusim MS VS Code, hlavne kvuli debuggeru.
    SPIRALI
    SPIRALI --- ---
    1 odpověď
    NYX: Rust Enhanced jsem mel v planu take vyzkouset. Nejaky konkretni zdroj nespokojenosti?

    btw: Umi uz RLS nebo rust-analyzer nejake vetsi refaktorizace? (napr. kdyz presunu soubor tak to opravi vsechny importy?)
    NYX
    NYX --- ---
    1 odpověď
    SPIRALI: Ja jedu v sublime + rust enhanced + rustfmt. Ale nejak zvlast spokojeny s tim nejsem teda.
    SPIRALI
    SPIRALI --- ---
    3 odpovědi+3
    Otazka pro vsechny: Jake pouzivate pro Rust IDE?

    Ja jsem prosel cestou Spacemacs -> vscode -> pycharm + rust plugin. Pycharm je pro mne horsi editor nez ty predchozi dva, ale k diky moznost refaktorizatorizace a obecne analyzy kodu u mne vyhrava. (Navic kolega byl jednu dobu nejaktivnejsi prispevatel do Rust pluginu, takze mam 1st-class support coz dost pomaha:)
    SPIRALI
    SPIRALI --- ---
    UETOYO: I kdyz to neni u zadne ISO-like organizace, tak jak to chapu ja, tak je specifikovano vse pomerne presne az na memory model. Coz je trochu problem pri psani unsafe kodu, ale trapi to primarne autory verifikacnich toolu, v praxi se uvazuje LLVM model (~ C++ model), na kterem ted stoji hlavni prekladac.
    FALL
    FALL --- ---
    UETOYO: pardon, moje chyba, špatně jsem to přečetl. Předpokládal jsem, že tam popisují cestu Rustu k RFC procesu u nějaké mezinárodní organizace typu ISO nebo IEEE, ale to je pouze popis interního RFC mechanismu v Rust "komunitě".

    Nicméně ta odpověď je hned o pár kliků vedle: https://doc.rust-lang.org/stable/ a https://github.com/rust-lang/rust

    Ano, není na tom nikde razítko nějaké "modré" organizace, ale jako specifikace všech částí mi to příjde dostatečné. Například C++ to dělá stejně (draft standardu je na githubu a konkrétní vydýání pak jen "otiskne" ISO).
    ELHO_CID
    ELHO_CID --- ---
    FALL: souhlasím, jsme tu trochu OT, ale kde je tu diskuze o MCU security? O žádné nevím.
    Fyzické útoky jsou oblast, kde klasické MCU končí a nastupují secure produkty, souhlasím. Ale i tam je ta hranice jen o kus dál a pokud má útočník k dispozici neomezený přísun virgin čipů, které si může rozlámat, tak se tím otvírají další možnosti. Nedostupnost těch čipů mimo okruh ověřených zákazníků je prostě součást security.
    FALL
    FALL --- ---
    UETOYO: hmmm, Google? https://www.rust-lang.org/governance
    FALL
    FALL --- ---
    1 odpověď+1
    ELHO_CID: uff, tahle diskuze se beojím odehrává ve špatném klubu, ale moderátor snad promine. Já mluvím o opravdovém kontaktním útoku, kdy má útočník fyzický přístup k té věci (čipu). Pro IoT zařízení a útoky z vnějšku "krabice" nebo dokonce útok na dálku přes internet/Bluetooth/atd. jsou ochrany typu secure boot, attestation atd. rozhodně dobrá věc a pokud je to napsané správně, můžou i při děravém stacku nebo chybě v aplikaci zabránit, aby útočník dostal data ven nebo aby dokázal nahrát vlastní firmware.

    Nicméně jakmile do obrazu přidáme útoky, kdy si to zařízení může útočník na pár dní půjčit domů a rozebrat, začíná být většina dnešních TrustZone implementací bezbranná, protože ty čipy nejsou stavěné na věci jako side channel/power analysis, glitching, probing atd. Takže s vybavením v řádech stovek až ticíců dolarů se útočník dostane "dovnitř" a ani TrustZone ani FW/loader/kernel napsaný v Rustu ti nepomůže. Viz například tato historka (nRF52840 má TrustZone a je mu to na nic):

    nRF52 Debug Resurrection (APPROTECT Bypass) Part 1 - LimitedResults
    https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/

    Ano, určitě jde vývoj dopředu a v kombinaci TrustZone + unmutable OTP paměť + PUF a podobné věci budou tyto útoky stále těžší, ale bez opravdu bezpečného návrhu daného čipu aby ustál ty běžné útoky (hádání klíčů za běhu z EM záření nebo spotřeby, glitching a aktivní útok na startovací sekvenci za běhu, přímé čtení paměti když se otevře pouzdro...) můžeš jen těžko vymyslet byznys model, ve kterém bys mohl garantovat ochranu věcí, které mají hodnotu větší, než řekněme 1000 dolarů (protože to bude cena, za kterou ti X lidí ochotně takový "běžný" čip vyláme v laboratoři, t.j. dostaneš veškerý kód a data a můžeš vesele začít dumat, jakou další chybu tam mají a jak jí využít už relativně levně na zbytku těchto zařízení rozesetých po světě...)
    Kliknutím sem můžete změnit nastavení reklam