5 ms·

How about cryptographically signed packages as the next step? It boggles my mind that most popular package managers like npm, pip and cargo don't have verificat

by jupp0r 4y ago

How about cryptographically signed packages as the next step? It boggles my mind that most popular package managers like npm, pip and cargo don't have verification of package authenticity before installing built in.

klysm 4y ago
I think HTTPS gets you pretty far. There are far more concerning attack vectors for those package ecosystems to me
- loic-sharma 4y ago
  Supply chain attacks are not uncommon. Package signing can protect against those: 1. Package source hacking. Say an attacker gets access to a package source's storage and inserts malware into popular packages. Now your project contains malware. Your package manager can detect tampering if the packages are signed. 2. Dependency confusion attacks. Say my project downloads packages from the public source as well as my company's private source. An attacker realizes my company has a private package named `private-foo` and uploads a malicious package with the same name to the public source. Now my projects contains malware as it occasionally downloads the malicious package instead of my company's private package. Your package manager can detect packages from an unexpected author if they are signed. I can provide more examples if you'd like. None of these are hypothetical, all of them have happened already.
  - kayodelycaon 4y ago
    > Dependency confusion attacks Just want to point out that bundler solves this problem (and many others). It pins gem versions in Gemfile.lock and it supports explicit source locations (like git repositories) for downloading gems.
- jacques_chester 4y ago
  HTTPS only protects the transmission from repository to user. It doesn't protect the package in the repository.
  - klysm 4y ago
    Yeah but what trust system are you going to use for that? I don’t see how anything at scale buys you too much
    - pabs3 4y ago
      The Linux distros use OpenPGP/X.509 keys stored on HSMs for their archive security, and a set of per-maintainer keys that are used to verify changes to the archive. RubyGems/Cargo/etc could use something like that.
- woodruffw 4y ago
  In this setting, HTTPS provides integrity (the authoritative party is the package index, which can serve you anything.) It can't provide authenticity, which is the root of most of the more interesting attack vectors in packaging.
jacques_chester 4y ago
RubyGems does have gem signing, but it's not widely used. There's a proposal for a new "one button" approach using sigstore[0]. Other ecosystems are also looking at sigstore too, and a lot of us are cooperating in the OpenSSF Securing Software Repos WG [1]. Package signing is a regular topic of discussion and there are various efforts underway. Disclosure: I am involved with both of these. [0] https://github.com/rubygems/rubygems.org/pull/2944 https://github.com/rubygems/rubygems.org/pull/2944 [1] https://github.com/ossf/wg-securing-software-repos https://github.com/ossf/wg-securing-software-repos
jshawl 4y ago
FWIW signed packages are available out of the box with rubygems: <http://docs.seattlerb.org/rubygems/Gem/Security.html http://docs.seattlerb.org/rubygems/Gem/Security.html>
- jacques_chester 4y ago
  Yes, but rarely used -- it's clunky. When I scraped the top 10k gems, < 1% had valid and up-to-date signatures.
  - jupp0r 4y ago
    Notably, signatures are not checked by bundler when installing gems.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
brigandish 4y ago
From [1]: > RubyGems has had the ability to cryptographically sign gems since version 0.8.11. This signing works by using the gem cert command to create a key pair, and then packaging signing data inside the gem itself. The gem install command optionally lets you set a security policy, and you can verify the signing key for a gem before you install it. > However, this method of securing gems is not widely used. It requires a number of manual steps on the part of the developer, and there is no well-established chain of trust for gem signing keys. Discussion of new signing models such as X509 and OpenPGP is going on in the rubygems-trust wiki, the RubyGems-Developers list and in IRC. The goal is to improve (or replace) the signing system so that it is easy for authors and transparent for users. I tried it years ago and it was such a pain that I stopped, and I've a high tolerance for this kind of thing. I also found problems with certificate chaining that I've forgotten about (intentionally and gladly). Basically, it was like a lot of security stuff over the years, half-baked, badly implemented, with a poor UI and hence, doesn't get used. [1] https://guides.rubygems.org/security/ https://guides.rubygems.org/security/
di 4y ago
PyPI supports uploading GPG signatures. Nobody uses it.

by jupp0r 4y ago

klysm 4y ago

I think HTTPS gets you pretty far. There are far more concerning attack vectors for those package ecosystems to me

loic-sharma 4y ago
Supply chain attacks are not uncommon. Package signing can protect against those: 1. Package source hacking. Say an attacker gets access to a package source's storage and inserts malware into popular packages. Now your project contains malware. Your package manager can detect tampering if the packages are signed. 2. Dependency confusion attacks. Say my project downloads packages from the public source as well as my company's private source. An attacker realizes my company has a private package named `private-foo` and uploads a malicious package with the same name to the public source. Now my projects contains malware as it occasionally downloads the malicious package instead of my company's private package. Your package manager can detect packages from an unexpected author if they are signed. I can provide more examples if you'd like. None of these are hypothetical, all of them have happened already.
- kayodelycaon 4y ago
  > Dependency confusion attacks Just want to point out that bundler solves this problem (and many others). It pins gem versions in Gemfile.lock and it supports explicit source locations (like git repositories) for downloading gems.
jacques_chester 4y ago
HTTPS only protects the transmission from repository to user. It doesn't protect the package in the repository.
- klysm 4y ago
  Yeah but what trust system are you going to use for that? I don’t see how anything at scale buys you too much
  - pabs3 4y ago
    The Linux distros use OpenPGP/X.509 keys stored on HSMs for their archive security, and a set of per-maintainer keys that are used to verify changes to the archive. RubyGems/Cargo/etc could use something like that.
woodruffw 4y ago
In this setting, HTTPS provides integrity (the authoritative party is the package index, which can serve you anything.) It can't provide authenticity, which is the root of most of the more interesting attack vectors in packaging.

jacques_chester 4y ago

RubyGems does have gem signing, but it's not widely used. There's a proposal for a new "one button" approach using sigstore[0]. Other ecosystems are also looking at sigstore too, and a lot of us are cooperating in the OpenSSF Securing Software Repos WG [1]. Package signing is a regular topic of discussion and there are various efforts underway. Disclosure: I am involved with both of these. [0] https://github.com/rubygems/rubygems.org/pull/2944 https://github.com/rubygems/rubygems.org/pull/2944 [1] https://github.com/ossf/wg-securing-software-repos https://github.com/ossf/wg-securing-software-repos

jshawl 4y ago

FWIW signed packages are available out of the box with rubygems: <http://docs.seattlerb.org/rubygems/Gem/Security.html http://docs.seattlerb.org/rubygems/Gem/Security.html>

jacques_chester 4y ago
Yes, but rarely used -- it's clunky. When I scraped the top 10k gems, < 1% had valid and up-to-date signatures.
- jupp0r 4y ago
  Notably, signatures are not checked by bundler when installing gems.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

brigandish 4y ago

From [1]: > RubyGems has had the ability to cryptographically sign gems since version 0.8.11. This signing works by using the gem cert command to create a key pair, and then packaging signing data inside the gem itself. The gem install command optionally lets you set a security policy, and you can verify the signing key for a gem before you install it. > However, this method of securing gems is not widely used. It requires a number of manual steps on the part of the developer, and there is no well-established chain of trust for gem signing keys. Discussion of new signing models such as X509 and OpenPGP is going on in the rubygems-trust wiki, the RubyGems-Developers list and in IRC. The goal is to improve (or replace) the signing system so that it is easy for authors and transparent for users. I tried it years ago and it was such a pain that I stopped, and I've a high tolerance for this kind of thing. I also found problems with certificate chaining that I've forgotten about (intentionally and gladly). Basically, it was like a lot of security stuff over the years, half-baked, badly implemented, with a poor UI and hence, doesn't get used. [1] https://guides.rubygems.org/security/ https://guides.rubygems.org/security/

di 4y ago

PyPI supports uploading GPG signatures. Nobody uses it.