Apparently one of my repos has a vulnerable package, but when I look it up it doesn't exist. Any ideas?
https://github.com/substack/minimist
https://www.npmjs.com/package/minimist
TL;DR
I think the author's GitHub account was hidden, deleted, or suspended.
Reasoning
The page https://github.com/substack also leads to a 404.
I found a July 2022 snapshot of the minimist github repo on archive.org. It looks like there were 43 open issues and 28 open PRs at that point, and the latest commit was 4 months prior, in March 2022. While 4 months isn't a long time, the number of open items may indicate that the maintainer didn't have enough time to keep working on the project. This is pure speculation on my point - I haven't tried to make contact or anything like that.
While the NPM unpublish policy and the NPM acceptable use policy define scenarios where the package could be removed entirely from NPM, it doesn't even appear to be deprecated. The package page is still up on the website.
GitHub policy allows for suspending or hiding a user account, or the user could easily have chosen to delete it for whatever reason.
My recommendation
Both the repository's README and https://security.snyk.io/vuln/SNYK-JS-MINIMIST-2429795 indicate that 1.2.6 fixes that security issue, so I would force that in your lockfile as soon as you have the bandwidth. If this is a transitive dependency, it may also be worth warning the maintainers of whichever package directly depends on minimist.
You do have another option, since the code is licensed under an MIT license. You (and/or anyone else who is interested) can choose to fork the code and build a fully-compatible replacement version of the package. Of course, you can also choose to switch to another argument-parsing library.
Related
The answer seems like 'no' but I wanted to check with colleagues here.
We provide an npm package for our own sites as well as some 3rd party sites.
There's a fairly heavy and old homegrown npm package that we also have in our package.
We don't need that package any longer on our sites but the 3rd party sites do.
We also have no way of controlling the code on those 3rd party sites so we need to keep the deployed bundle name and location the same for them.
Is there a way to publish a version of our package first without the extra package for us and then a version with it for the third parties from the same repository?
ourpackage-new.js (without the dependency)
ourpackage.js (with the dependency)
I had some success with a new package json in a subdirectory. I would create a new package and the original package via a command in gitlab.yaml to cd into that directory and npm publish there after the first one. This requires copying some dependency files down there as well which would mean if one version was updated, we'd need to remember to update the copy. Not a situation we'd want.
Even if we created a 2nd repository for the change just for us, we'd still need to update 2 repositories every time we had a new change to deploy.
Checked into Aliasing as well, we wouldn't be planning to import a new version and an old version though, more like sister versions.
In any case, thanks for the input and thoughts. I realize Npm was prob not made for this type of situation. If I remember right, I could do this with Gulp years ago, but I haven't even thought about Gulp in so long :) And then, I'd have to deploy manually via an FTP program ... wow, those were days.
Thanks again!
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
Given the news that npm 5.7.0 had some issues in production, I'm wondering if it's possible to blacklist a package version either in package.json or on the machine level perhaps in .npmrc or .yarnrc.
The behaviour I'm expecting is that upgrades are possible, so this is not a fixed semver version. SemVer has intentionally avoided defining version skipping in the spec because,
SemVer is meant to communicate what type of changes have occurred, not
'how much' change has occurred. If a user wants to know the details of
how much has changed, they should look at the changelog. A long
changelog tells them it's a big update.
But as a user I may know beforehand that I never want this version. For example, never use 5.7.0 but 5.7.1 is ok.
If you have package A that depends on B and B has a known bad version, you can define a version range with a hole in it. See last paragraph of https://docs.npmjs.com/misc/semver. I am not aware of any way to globally black-list such a version on your system however, so if you install A and it doesn't have a version hole on its dependency on B, you might have gotten the bad version, but in the example you state above, the offending version was pulled from publication as the news was released regarding the defect.
One thing you can do is purge your cache of any bad package versions to insure that they can't be used to resolve dependencies.
I consider to use Hexo (the static blog generator) based on npm. I wonder one thing, what if although one npm package (dependency) will not be longer available? Each package has its own author and it can cancel support or completely remove it from npm's repository at any time.
So what do I do if missing one of the npm package affect on running Hexo and consequently I'll not be able to generate my blog in the future?
Although this can happen (and happened at least once), it is not a serious problem ussually. While you will be waiting until somebody will fix the missing dependency (it take place quickly on popular packages like Hexo) you can use older working version. And if you want to be 100% sure, you can commit node_modules together with your web sources (see discussion here).
My standard route has been to go to confluence, find the docs sections, then navigate through to the install docs for the version, e.g. sakai 10:
https://confluence.sakaiproject.org/x/iYGLBQ
Through one means or another I happened across the source route to this too, so starting here....
http://source.sakaiproject.org/release/
You get redirected to the latest stuff, and appended version numbers to that url gives you other docs, e.g. adding 2.8.2 or 10 to the end of the url
But the links to what I should download are quite often not there, at the time of writing the 10 tar ball and zip in the confluence links are dead and the source.sakaiproject links doesn't have the 10 docs yet (redirects to 2.9.3) presumably this is because v10 is not released yet....
So, I'd like to evaluate a new version of a sakai source install, what's the best way to do this? (considering the official documentation for install is still being formed)
Do I download the latest SVN, or the latest RC or the latest beta or??? How do I know what's best to test against without being "too" bleeding edge? Is there a recommended tar ball/zip link to test against? Is there a "latest good" SVN branch?
The latest code is always in the Sakai trunk (currently svn):
https://source.sakaiproject.org/svn/sakai/trunk/
That code may very well not be stable though as it is where things are being actively developed. If you are not actively developing then you should stick to the releases as indicated on the project website here:
http://sakaiproject.org/current-release
If you want to use something in between (say an upcoming release) then you can grab the most recent tag or maybe use a recent branch (both currently in svn, latest shown below at the time I write this):
https://source.sakaiproject.org/svn/sakai/branches/sakai-10.x/
https://source.sakaiproject.org/svn/sakai/tags/sakai-10-rc02/
The reality of the situation is that if you want to use something other than the release then you should really participate in the dev community for Sakai. Joining the mailing lists and the weekly calls will provide the information you are asking about and much more.