Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
@forest-fire/fire-layer
Advanced tools
An AWS layer which includes a strong baseline of requirements for users who use Firemodel and Universal-Fire
This repo produces a AWS Layer which includes the baseline of requirements that'll need in AWS to use apps leveraging Firemodel. The top level dependencies which this layer will provide includes:
Your Lambda functions which include this layer will find these top level dependencies along with their dependency graphs are what you will find in this layer in the /opt/node_modules
filesystem. In order for your functions import statements to properly resolve this path you will need to ensure that the NODE_PATH
ENV variable is set to include the mount directory above.
The following table would describes the package version that each version of fire-layer
released contains:
AWS layer version | fire-layer | firemodel | universal-fire | firemock |
---|---|---|---|---|
1 | 0.58.0 | 0.58.0 | 0.58.0 | 0.58.0 |
2 | 0.58.1 | 0.58.0 | 0.58.0 | 0.58.0 |
3 | 0.59.0 | 0.59.0 | 0.59.0 | 0.59.0 |
If you are using the serverless framework, you'd simply add something like the following to your serverless.yaml
file:
functions:
MyFunction:
layers:
- 'arn-path-to-this-layer'
environment:
NODE_PATH: "./node_modules:/opt/node_modules"
alternatively if you're using this layer in many places, or have other layers which drop NPM deps into opt/node_modules
then you can just add it to your global environment:
provider:
name: aws
runtime: nodejs14.x
environment:
NODE_PATH: "./node_modules:/opt/node_modules"
You're actual config will clearly vary based on your needs but a common strategy is to have a env.yaml
where you'll put all your non-secret ENV variables and then refer to this file in your master serverless.yaml
like so:
provider:
environment: '${file(serverless-config/env.yml):${self:custom.stage}}'
This then allows you configure your env.yml
with per-stage as well as global ENV variables and tends to work much better than trying to fit it all into the serverless.yml
. Here's an example of what it might look like:
global: &all_stages
MY_SILLY_API: "xxyyzz234324"
dev:
<<: *all_stages
FIREBASE_DATABASE_URL: "https://test.firebase.com"
prod:
<<: *all_stages
FIREBASE_DATABASE_URL: "https://prod.firebase.com"
You can either reference the ARN of this layer's formal deployment or just deploy it locally into your own account. To deploy it to your own account:
# install local dev-deps
yarn
# builds layer and deploys using serverless framework
yarn deploy
Otherwise you can just refer to the following ARNs:
firebase-admin
(9.5.x)FAQs
An AWS layer which includes a strong baseline of requirements for users who use Firemodel and Universal-Fire
We found that @forest-fire/fire-layer demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.