The Crystal Programming Language Forum

Malware detection/notification

Perhaps it’s time to plan for supply chain attacks before crystal is targetted.

Todo items:

  • Set a security policy that details how to report vulnerabilities.
  • TBD


1 Like

As a security guy (blue team) I am supporting this effort!

The Crystal team does not run any infrastructure for the ecosystem. Shards is designed as a decentral package manager. As such there’s no place to enforce any such policy, each project has and should set their own. Of course we can think about providing recommendations or templates for this in some way or another, possibly as part of crystal init. But let’s not pretend like this is something we can reasonably enforce.

This lack of central infrastructure also means that we cannot build up a central emergency response team that could reasonably act. It could neither remove any vulnerable software from the ecosystem nor directly release patched versions.

Something we can do to help the ecosystem is however to provide a central collection point for these kinds of reports, something akin to for example https://rubysec.com/ (this used to provide a subscribable feed of advisories). This does not necessarily need to be an effort by the core Crystal team, but an easy start here could be a moderated category in this forum or a mailing list, where project owners can submit advisories, CVE entries etc. for their projects that users can subscribe to. Of course that doesn’t scale as the ecosystem grows, but might be good enough for now.

Now the second part of exploration here, that we probably should split into its own thread in case we decide to research this deeper, is code signing. In principle it should be fairly easy to validate the signature of for example git tags while installing dependencies with shards. But here again the lack of central infrastructure comes to bite us. Managing trust anchors in a decentral system is quite the rabbit hole, trust me. Especially in bigger projects you don’t want to bind being able to release to a single key or person. Key rotation also becomes a mess. Having to manually maintain the current signing keys of all dependencies will make people just not use the feature. In my ideal world we would just put keys into a DNSSEC signed zone, so you could add a signed dependency by something like

dependencies:
  foo:
    github: jhass/crystal-foo
    signers: shardkeys.jhass.eu

which would then fetch valid keys or key fingerprints or so via a TXT record of that zone. But facing reality, the state of DNSSEC in resolvers, home routers and people’s minds is just too dire. So I don’t have good ideas here.

1 Like

Shards is designed as a decentral package manager.

Nothing precludes shards from checking a central advisory list for malware. There’a a lot shards can do like locking git hashes in shard.lock that hasn’t been mentioned here (yet).

This lack of central infrastructure also means that we cannot build up a central emergency response team that could reasonably act.

False. See below.

It could neither remove any vulnerable software from the ecosystem nor directly release patched versions.

True, except shards could provide links to advisories, recommended courses of action, new repositories with patched software and more.

@jhass we should respond only to the Standard Library and compiler vulnerabilities.
Any shards can be scanned in the way how npm audit works and notify authors about found vulnerabilities. Until vulnerability is resolved it should show the message in shards install that specific shard has vulnerability.

But then it’s no longer fully decentralized. :smiley:
Not say it would not be worth considering, just that it has implications like adding a single point of failure.

The advisory list could be published either on github for the exact same single point of failure as most shard repos or using any number of distributed or mirrored data distribution services.