• 0 Posts
  • 13 Comments
Joined 2 months ago
Cake day: September 5th, 2026
  • borosilicate@lemmy.dbzer0.comtoTechnology@beehaw.org•Some iPhone Duo displays are cracking, seemingly all in the same way
    7·
    9 days ago

    My best friend has has had the Samsung version of this for four different generations now. I’ve always been a hater about it but now in gen 4, there are very few issues with Samsung’s folding phones… but they still suck and are fragile as hell.
    My conclusion: all folding screen phones like this are shite and Apple gets a first generation mulligan on this one. This release is as bad as any in their history and they should have seen it coming a mile away given Samsung’s myriad issues.

    My rule: NEVER BUY AN OVERPRICED, GIMMICKY, FIRST-GENERATION APPLE PRODUCT.

  • borosilicate@lemmy.dbzer0.comtoRust@programming.dev•Signal Protocol in Rust
    21·
    11 days ago

    I used a frontier model to generate an allium spec from your repo and it found a few bugs. I like to run apps through allium to prepare for formal verification because it tends to find a LOT of flaws in even the most robust apps. The allium spec file is too large to share here but it can be generated by any frontier model.

    Defects, three of them confirmed by running probes against the crate:

    • P1, a late message from the previous chain breaks the session. The decrypt code never keeps the leftover keys of the old receiving chain, and it reads the header’s previous chain length only as associated data. So a delayed message from the old chain looks like a new ratchet key. The session steps the ratchet again and the tag fails. In the probe, the next good message also failed with an AES-GCM error. Signal handles exactly this case, and the crate’s out-of-order test only reorders messages within one chain.
    • P2, one forged message with a made-up ratchet key desyncs the session for good. The ratchet step and key skipping happen before the tag is checked, and they’re never rolled back. In the probe, the next real message failed.
    • P3, a forged message naming a skipped key deletes that key before the tag check. The real message then fails with “Message number mismatch”.
    • The signed prekey’s signature is never checked. x3dh_initiate_internal doesn’t call verify_signed_prekey, and the WASM API doesn’t expose it. Prekey authentication depends on every application remembering to do it.
    • The X3DH associated data isn’t bound to the two identities. It’s the constant “X3DH_Key_Exchange” rather than both identity keys, and the ratchet never uses it anyway.
    • The identity key and the signing key are unrelated. It uses a separate, unbound Ed25519 signing key instead of XEdDSA on the identity key.
    • The first chain gets no DH ratchet. On both sides it’s derived from the X3DH secret alone.
    • Smaller issues:
      • There’s no cap on the total number of skipped keys.
      • Cleanup drops keys in string order, not oldest first.
      • The send counter is a u32 with no overflow check.
      • The DH output isn’t checked for all-zero values from small-order keys.
      • The legacy encrypt_message helper returns the message key to JavaScript. Variants, not defects: the non-standard HKDF salts and info strings. Both sides agree on them, and the spec says so.
    -- VIOLATED: only one decrypt's skip is capped (max_skip); nothing caps
-- the total unless the application calls cleanup, so a peer that keeps
-- skipping grows the state without limit.
invariant SkippedKeysAreBounded {
    for s in Sessions:
        s.skipped.count <= config.max_skipped_total
}

invariant OneTimePreKeysBelongToOneSession {
    for a in Handshakes:
        for b in Handshakes:
            a != b and a.one_time_prekey != null
                implies a.one_time_prekey != b.one_time_prekey
}

invariant ResponderCannotSendBeforeReceiving {
    for s in Sessions:
        s.role = responder and s.receiving_ratchet_public = null
            implies s.sending_chain_key = null
}

open question "Should x3dh_initiate_internal take the signing key and signature and verify the signed prekey itself, so a caller cannot skip it?"

open question "Should the identity key sign with XEdDSA, so there is one long-term key instead of an unbound X25519 and Ed25519 pair?"

open question "Should decrypt work on a copy of the state and commit only after the tag verifies?"

open question "Should the associated data be IK_A || IK_B and be passed into every seal and open?"
  • borosilicate@lemmy.dbzer0.comtoProgramming@programming.dev•Executable Scripts with Dependencies
    21·
    2 months ago

    Well said. I’m glad people are challenging my json characterization. I deserve the flack but perhaps it was just a sensationalist headline to get some discussion going. It worked. ;)

    Thanks for the valuable anecdotal evidence. You do speak the truth. I’ve settled on the fact that the community will never agree to adopt flakes.

    Personally, I have an opinionated stack that is, at this point, self documenting. I maintain a strict style where I add assertions to most things that nix won’t be able to prove conclusively with just a build and cheaper checks that I run before actually building any real derivations. As I said elsewhere, Nix feels like the revolutionary precursor to a sea change in dependency management. But it’s just that: an imperfect technology with enough great ideas for me to adopt it wholesale and use fixing and finding ways around the warts as a way to give back to this open source community.

  • borosilicate@lemmy.dbzer0.comtoProgramming@programming.dev•Executable Scripts with Dependencies
    41·
    1 month ago

    No problem. Thanks for being friendly.

    Not RTFM territory at all! ☺️ The manual is honestly one of Nix’s weaker points.

    1. No generator, I wrote those by hand. The multi-line one looks scarier than normal usage though. 95% of the time the whole thing is one line: #! nix shell nixpkgs#ripgrep nixpkgs#jq --command bash. The two ugly bits in my examples both come from a command. The commit hash is nix flake metadata github:NixOS/nixpkgs/nixos-unstable --json | jq -r .locked.rev. The sha256 for the jar I got the lazy way: put a fake hash in, run it, and Nix fails with “specified X, got Y”. Paste Y in. Everybody does it that way and though it can be considered “hacky” you only have to do that dance once when you declare or want to update it to the latest hash.

    For anything bigger than a script you don’t write hashes at all. You write a flake.nix that says “nixpkgs, unstable branch” and Nix generates a flake.lock with the exact commit and hashes, same idea as Cargo.lock or package-lock.json.

    1. Yes, and this is the thing Nix is best at. One naming trap first: for “current stable release of the language” you want the nixos-unstable branch. “Unstable” means the package set rolls forward, not that the packages are betas. It has whatever the latest stable Go/Rust/GHC/etc is, usually within days, and it only advances after the test suite passes. The “stable” branches (nixos-26.05 and so on) freeze versions for six months, which is what you want for a server and usually not for a dev box.

    A dev environment is a flake.nix in the repo root:

    {
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

  outputs = { self, nixpkgs }:
    let
      systems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
      forAllSystems = f: nixpkgs.lib.genAttrs systems (system: f nixpkgs.legacyPackages.${system});
    in
    {
      devShells = forAllSystems (pkgs: {
        default = pkgs.mkShell {
          packages = [
            pkgs.go
            pkgs.gopls
            pkgs.ripgrep
          ];
        };
      });
    };
}

    nix develop drops you into a shell with exactly those. First run writes flake.lock, you commit it, and everyone who clones the repo gets identical versions without having to download a bloated Docker image (instead running those dependencies natively in Nix’s sandbox). Updating is nix flake update and then commit the lock. Nothing moves until you run that, so you update when you choose to and if something breaks you git checkout flake.lock and you’re back. If you want it automated there’s a GitHub action (DeterminateSystems/update-flake-lock) that opens a PR with the bumped lock on a schedule, and Renovate handles flake.lock too.

    Add direnv + nix-direnv and the shell loads on cd into the project, so you never type nix develop again. That’s the point where it stops feeling like extra work.

    For personal tools like nvim and ripgrep that you want everywhere and not per project: quick way is nix profile install nixpkgs#neovim nixpkgs#ripgrep and later nix profile upgrade --all. The idiomatic way is home-manager, where your tool list and dotfiles live in one flake in a git repo and a new machine is a clone plus one command. I’d start with the profile commands and a devShell in one project, and only look at home-manager once you’re sure you like it.

    One caveat: for Rust, if you need an exact toolchain version or nightly, nixpkgs only carries current stable, so people use fenix or rust-overlay as a second flake input to declare specific builds in the closure. Most other languages just have versioned attributes like pkgs.python312 or pkgs.jdk21.

  • borosilicate@lemmy.dbzer0.comtoProgramming@programming.dev•Executable Scripts with Dependencies
    122·
    2 months ago

    Resident (evidently unwelcome) nix evangelist chiming in here.

    The article is about scripts that declare their own dependencies. I wrote another response lamenting the fact that we are talking about dependencies without mentioning IMO the best way to handle dependencies in a script and got flamed by a toxic luddite:

    NIX is the answer.

    Look at what actually gets declared in the article: the library version goes in the file, and the thing that runs the file is whatever brew install hands you that second. Going through OP’s examples:

    Ruby: gem "optimist" has no version at all. Every machine resolves it to whatever is newest on first run.

    Rust: cargo +nightly -Zscript. The +nightly syntax is a rustup proxy feature, so a distro-packaged cargo won’t even parse it. Nightly is a different compiler every day, -Zscript is unstable and its frontmatter syntax has already changed once, clap = "4" and anyhow = "1" are ranges, and there’s no Cargo.lock. Nothing about that script is fixed except its text.

    Haskell: optparse-applicative is pinned exactly, but base >= 4.18 && < 5 accepts any GHC from 9.6 up, and the transitive deps get solved against whatever cabal update fetched. Two people running it a month apart get two build plans. You can add an index-state in a {- project: -} block, which helps with Hackage and does nothing for GHC.

    Python: typer is exact, click and rich and the rest float, and >=3.10 is any interpreter. uv lock --script fixes that by writing a second file, at which point it’s no longer a single-file script.

    Also env -S needs coreutils 8.30+ or a BSD env, and every prerequisite listed is Homebrew on macOS.

    The biggest gap is that none of the examples touches a C library. The first script that needs libpq or openssl or zlib headers is outside what NuGet, Hackage, crates.io or PyPI can describe. You’re back to brew/apt and whatever version happens to be installed.

    Nix has been usable as a shebang interpreter for YEARS, so here is the Haskell example with the compiler, every library, and libc pinned by one commit hash:

    #!/usr/bin/env nix
#! nix shell --impure --expr ``
#! nix with (builtins.getFlake ''github:NixOS/nixpkgs/e554fab72f81915600f3f449b786fd9af40439a5'').legacyPackages.${builtins.currentSystem};
#! nix ghc.withPackages (ps: [ ps.optparse-applicative ])
#! nix ``
#! nix --command runghc

import Options.Applicative

data Options = Options
  { name :: String
  }

options :: Parser Options
options =
  Options
    <$> strArgument
      ( metavar "NAME"
     <> help "Name to greet"
      )

main :: IO ()
main = do
  opts <-
    execParser $
      info
        (options <**> helper)
        (fullDesc <> progDesc "Say hello")

  putStrLn $ "Hello, " <> name opts <> "!"

    --impure is only there so it can read the current system. Same GHC and same build of every dependency on any Linux or macOS box, today or in a hundred fifty years. Native deps are the same mechanism: add postgresql to the list.

    When the library isn’t in nixpkgs, nix users pin the artifact by content hash. The article’s babashka example downloads org.babashka/cli from Clojars at runtime. Here the jar is a fixed-output fetch handed to bb on its classpath, so nothing gets resolved when the script runs:

    #!/usr/bin/env nix
#! nix shell --impure --expr ``
#! nix with (builtins.getFlake ''github:NixOS/nixpkgs/e554fab72f81915600f3f449b786fd9af40439a5'').legacyPackages.${builtins.currentSystem};
#! nix let cli = fetchurl { url = ''https://repo.clojars.org/org/babashka/cli/0.12.91/cli-0.12.91.jar''; hash = ''sha256-HPvn4scG4lHZJJLPpXV5ZqbQ17aFZ64AC4fmF5B2HHs=''; };
#! nix in runCommand ''bb-pinned'' { nativeBuildInputs = [ makeWrapper ]; } ''makeWrapper ${babashka}/bin/bb $out/bin/bb-pinned --set BABASHKA_CLASSPATH ${cli}''
#! nix ``
#! nix --command bb-pinned

(require '[babashka.cli :as cli] :reload)

(defn hello [{:keys [name]}]
  (println (str "Hello, " name "!")))

(cli/dispatch
  [{:exec-fn hello
    :args->opts [:name]
    :spec {:name {:positional true :require true :desc "Name to greet"}}}]
  *command-line-args*
  {:prog "hello" :help true})

    The :reload matters: bb bundles its own copy of babashka.cli, and without it the require keeps the bundled one. If Clojars ever serves different bytes for that URL, the script refuses to run. This works for a jar with no transitive deps, which this one is. A real dependency tree needs a generated lock file, and at that point you want a flake.nix and flake.lock next to the script, with nix run replacing the shebang.

    What you don’t get for free just by choosing Nix: you need Nix installed (one prerequisite instead of one per language), flakes are still behind an experimental flag upstream, first run is slow, evaluation adds a few hundred ms per run, and the five-line shebang is uglier than anything in the article. And if you write nixpkgs#babashka without a rev you’ve pinned nothing, it follows the registry.

    So I’d say it belongs in the list. It’s the only entry where the interpreter is part of what the script declares.