• 4 Posts
  • 1.67K Comments
Joined 3 years ago
cake
Cake day: June 12th, 2023

help-circle

  • Absolutely this.

    33 years in Linux, 30+ professionally, Unix+Linux security background in a past life at a fucking distro.

    When I first install a new distro version, I do something very simple; maybe I configure a simple web page, for instance.

    Usually the web server refuses to start, or something equally “so dumb it should have been seen in early testing and doesn’t even get to the challenge I set before it” stupid. If the distro can’t test something so basic, then I know they’re not prepared to consider selinux implications while maintaining or debugging the distro. I don’t need to blaze a trail the distro can’t be arsed to.

    Then I mod away the config in my template and hope the distro can pull out their proverbial head in 5 years.

    The easiest path needs to be the safest path










  • corsicanguppy@lemmy.catoTechnology@lemmy.mlan appeal to abandon Spotify
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    5 days ago

    But the moment after showing LPs had this trope, it suggests album purchases – which had this trope.

    I bought Finger Eleven, wanting an album of Paralyzed. I bought Mezzanine, wanting 10 tracks of Dissolved Girl.

    In each case I got something else which eventually grew on me for the artistry it was, but in the moment I felt hoodwinked.







  • corsicanguppy@lemmy.catoProgramming Humor@lemmy.worldnpm
    link
    fedilink
    English
    arrow-up
    2
    ·
    9 days ago

    composer/packagist has the exact same dependency security risks as node.js.

    (Reposted)

    Objectively, they all frustrate validation the same. When comparing with a SLSA3-compliant setup where every installed artifact has a signed checksum in a signed bundle from a signed resource on a signed repository, and the endpoint to this is readily available from something like authenticated SNMP into the single source of truth, they all tends to compare poorly.

    The chart below completely ignores that Debs are consolidated into a single source of truth as well, and I feel violating SSoT should cost significantly because of dependency holes when artifact registry is incomplete, but SLSA doesn’t care about that part.

    Ecosystem / Format Estimated SLSA Level Update Reliability / Model Trust Chain & Provenance Comments
    (withheld) 3–4 Very high; repo-based, transactional updates Strong: signed packages + signed repo metadata + central DB; distros enforce reproducible builds.
    OCI containers (hardened pipeline: cosign + Tekton/in-toto) 3 High if using automated CI/CD and policy enforcement Strong if you use signed images + non-falsifiable provenance; this is rare but achievable.
    DEB (distro repos) 2 High; repo-based, APT handles dependencies Medium: repo metadata signed, but per-package signatures not mandatory; weaker checksum chain.
    Flatpak runtimes (Flathub) 2 High; centralized runtimes, predictable updates Medium: signed OSTree commits; build infra more centralized, but not full end-to-end provenance.
    Flatpak apps 1–2 High; repo-based, automatic updates Mixed: OSTree signing helps, but build provenance varies by publisher; no uniform SLSA guarantees.
    Snap (strict confinement) 1–2 High; centralized store, auto-updates Centralized signing by Canonical, but opaque build pipelines; trust is “trust the store operator.”
    OCI containers (typical public images) 0–1 Medium; pull-latest model, tag drift common Usually unsigned; mutable tags; no guaranteed provenance—trust is mostly social and reputation-based.
    Snap (classic confinement) 1 High; same store/auto-update model Same store trust, but classic snaps bypass sandbox; even more reliance on publisher integrity.
    AppImage 0–1 Low–medium; ad-hoc self-update or manual downloads Almost no chain of custody; signatures optional; no central repo or provenance expectations.
    npm (JavaScript) 0–1 High frequency, but low reliability of safety; semver + lockfiles Registry accounts can publish arbitrary tarballs; no default signed provenance; transitive deps explode risk.
    PyPI / pip (Python) 0–1 Similar to npm; pip + requirements/lockfiles Tarballs/wheels from arbitrary maintainers; no mandatory signing; provenance work (e.g., PEP 740) is emerging but not standard.
    Composer / Packagist (PHP) 0–1 Good tooling, but same “trust the registry” model Packages pulled from Packagist/VCS; no mandatory signatures; dependency graph trust is social, not cryptographic.
    CPAN (Perl) 0–1 Mature ecosystem, but manual/legacy in many flows Historically minimal provenance; mirrors and authors are trusted by convention, not by SLSA-style attestations.
    Other language registries (RubyGems, crates.io, etc.) 0–1 Similar to npm/PyPI; lockfiles help reproducibility Central registries, but no default SLSA provenance; integrity is mostly TLS + registry operator trust.



  • why avoid Flatpak? I get snap or AppImage,

    Objectively, they all frustrate validation the same. When comparing with a SLSA3-compliant setup where every installed artifact has a signed checksum in a signed bundle from a signed resource on a signed repository, and the endpoint to this is readily available from something like authenticated SNMP into the single source of truth, they all tends to compare poorly.

    The chart below completely ignores that Debs are consolidated into a single source of truth as well, and I feel violating SSoT should cost significantly because of dependency holes when artifact registry is incomplete, but SLSA doesn’t care about that part.

    Ecosystem / Format Estimated SLSA Level Update Reliability / Model Trust Chain & Provenance Comments
    (withheld) 3–4 Very high; repo-based, transactional updates Strong: signed packages + signed repo metadata + central DB; distros enforce reproducible builds.
    OCI containers (hardened pipeline: cosign + Tekton/in-toto) 3 High if using automated CI/CD and policy enforcement Strong if you use signed images + non-falsifiable provenance; this is rare but achievable.
    DEB (distro repos) 2 High; repo-based, APT handles dependencies Medium: repo metadata signed, but per-package signatures not mandatory; weaker checksum chain.
    Flatpak runtimes (Flathub) 2 High; centralized runtimes, predictable updates Medium: signed OSTree commits; build infra more centralized, but not full end-to-end provenance.
    Flatpak apps 1–2 High; repo-based, automatic updates Mixed: OSTree signing helps, but build provenance varies by publisher; no uniform SLSA guarantees.
    Snap (strict confinement) 1–2 High; centralized store, auto-updates Centralized signing by Canonical, but opaque build pipelines; trust is “trust the store operator.”
    OCI containers (typical public images) 0–1 Medium; pull-latest model, tag drift common Usually unsigned; mutable tags; no guaranteed provenance—trust is mostly social and reputation-based.
    Snap (classic confinement) 1 High; same store/auto-update model Same store trust, but classic snaps bypass sandbox; even more reliance on publisher integrity.
    AppImage 0–1 Low–medium; ad-hoc self-update or manual downloads Almost no chain of custody; signatures optional; no central repo or provenance expectations.
    npm (JavaScript) 0–1 High frequency, but low reliability of safety; semver + lockfiles Registry accounts can publish arbitrary tarballs; no default signed provenance; transitive deps explode risk.
    PyPI / pip (Python) 0–1 Similar to npm; pip + requirements/lockfiles Tarballs/wheels from arbitrary maintainers; no mandatory signing; provenance work (e.g., PEP 740) is emerging but not standard.
    Composer / Packagist (PHP) 0–1 Good tooling, but same “trust the registry” model Packages pulled from Packagist/VCS; no mandatory signatures; dependency graph trust is social, not cryptographic.
    CPAN (Perl) 0–1 Mature ecosystem, but manual/legacy in many flows Historically minimal provenance; mirrors and authors are trusted by convention, not by SLSA-style attestations.
    Other language registries (RubyGems, crates.io, etc.) 0–1 Similar to npm/PyPI; lockfiles help reproducibility Central registries, but no default SLSA provenance; integrity is mostly TLS + registry operator trust.