
Research
SANDWORM_MODE: Shai-Hulud-Style npm Worm Hijacks CI Workflows and Poisons AI Toolchains
An emerging npm supply chain attack that infects repos, steals CI secrets, and targets developer AI toolchains for further compromise.
ejpm
Advanced tools
ejpm stands for eJANA packet manager helper
The main goal of ejpm is to provide easy experience of:
The secondary goal is to help users with e^JANA plugin development cycle.
TL;DR; example for CentOS/RHEL7
# INSTALL PREREQUESTIES
ejpm req centos ejana # get list of OS packets required to build jana and deps
sudo yum install ... # install watever 'ejpm req' shows
# or if you are a lucky bash user (yes, csh is still common in physics):
sudo yum install $(ejpm req centos ejana --all)
# SETUP EJPM
ejpm --top-dir=<where-to> # Directory where packets will be installed
ejpm set root `$ROOTSYS` # (optional) if you have CERN.ROOT or other monster packets:
# INSTALL PACKETS
ejpm install ejana # install ejana and dependencies (like genfit, jana and rave)
ejpm install g4e # install 'Geant 4 EIC' and dependencies (like vgm, hepmc)
# SET RIGHT ENVIRONMENT
source<$(ejpm env) # set environment variables,
source ~/.local/share/ejpm/env.sh # more convenient way. Use *.csh file for tcsh
ejpm is here as there is no standard convention in HEP and NP of how to distribute and install software packages with its dependencies. Some packages (like eigen, xerces, etc.) are usually supported by OS maintainers, while others (Cern ROOT, Geant4, Rave) are usually built by users or other packet managers and could be located anywhere. Here comes "version hell" multiplied by lack of software manpower (e.g. to continuously maintain packages on distros level or even to fix GitHub issues) Still we love our users and try to get things easier for them! So here is ejpm.
At this points ejpm tries to unify experience and make it simple to deploy e^JANA for:
It should be as easy as > ejpm install ejana to build and install a packet called 'ejana'
and its dependencies. But it should also provide a possibility to adopt existing installations
and have a fine control over dependencies: > ejpm set root /opt/root6_04_16
ejpm is not:
Step by step explained instruction:
Install prerequisites utilizing OS packet manager:
# To see the prerequesties
ejpm req ubuntu # for all packets that ejpm knows
ejpm req centos ejana # for ejana and its dependencies only
# To put everything into packet manager
apt-get -y install `ejpm req ubuntu --all` # debian
yum -y install `ejpm req centos --all` # centos/centos
At this point only 'ubuntu' and 'centos' are known words for req command. Put:
In the future this will be updated to support macOS and to have more detailed versions
Set top-dir. This is where all missing packets will be installed.
ejpm --top-dir=<where-to-install-all>
Register installed packets. You may have CERN.ROOT installed (req. version >= 6.14.00). Run this:
ejpm set root `$ROOTSYS`
You may set paths for other installed dependencies combining:
ejpm install ejana --missing --explain # to see missing dependencies
ejpm set <name> <path> # to set dependency path
Or you may skip this step and just get everything installed by ejpm
Install ejana and all missing dependencies:
ejpm install ejana
Set environment. There are 3 ways for doing this this:
Dynamically source output of ejpm env command (recommended)
source <(ejpm env) # works for bash only
Save output of ejpm env command to a file (can be useful)
ejpm env sh > your-file.sh # get environment for bash or compatible shells
ejpm env csh > your-file.csh # get environment for CSH/TCSH
Use ejpm generated env.sh and env.csh files (lazy and convenient)
$HOME/.local/share/ejpm/env.sh # bash and compatible
$HOME/.local/share/ejpm/env.csh # for CSH/TCSH
(!) The files are regenerated each time ejpm <command> changes something in EJPM.
If you change db.json by yourself, ejpm doesn't track it automatically, so call 'ejpm env'
to regenerate these 2 files
EJPM_DATA_PATH- sets the path where the configuration db.json and env.sh, env.csh are located
Each time you make changes to packets,
EJPM generates env.sh and env.csh files,
that could be found in standard apps user directory.
For linux it is in XDG_DATA_HOME:
~/.local/share/ejpm/env.sh # sh version
~/.local/share/ejpm/env.csh # csh version
~/.local/share/ejpm/db.json # open it, edit it, love it
XDG is the standard POSIX paths to store applications data, configs, etc. EJPM uses XDG_DATA_HOME to store
env.sh,env.cshanddb.jsonanddb.json
You can always get fresh environment with ejpm env command
ejpm env
You can directly source it like:
source<(ejpm env)
You can control where ejpm stores data by setting EJPM_DATA_PATH environment variable.
FAQs
EIC Jana Package Manager
We found that ejpm demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer 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
An emerging npm supply chain attack that infects repos, steals CI secrets, and targets developer AI toolchains for further compromise.

Company News
Socket is proud to join the OpenJS Foundation as a Silver Member, deepening our commitment to the long-term health and security of the JavaScript ecosystem.

Security News
npm now links to Socket's security analysis on every package page. Here's what you'll find when you click through.