scottlamb / moonfire-nvr

Moonfire NVR, a security camera network video recorder
Other
1.29k stars 143 forks source link

What Version Of Yarn? #110

Closed jlpoolen closed 3 years ago

jlpoolen commented 3 years ago

The instruction guide at: https://github.com/scottlamb/moonfire-nvr/blob/master/guide/build.md has:

Finally, building the UI requires yarn. (On macOS, the brew command above installs it for you.
 On Linux, follow yarn's guide.) 
  [There is a link under "yarn" that has: "https://yarnpkg.com/en/" which when clicked 
  resolves to https://classic.yarnpkg.com/en/.]

I tried following instructions and ended up with an invalid signature package.

pi@raspberrypi:/usr/local/src/moonfire-nvr $ cd ui
pi@raspberrypi:/usr/local/src/moonfire-nvr/ui $ yarn
yarn install v1.22.4
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.13: The platform "linux" is incompatible with this module.
info "fsevents@1.2.13" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
warning Your current version of Yarn is out of date. The latest version is "1.22.5", while you're on "1.22.4".
info To upgrade, run the following command:
$ sudo apt-get update && sudo apt-get install yarn
Done in 175.84s.
pi@raspberrypi:/usr/local/src/moonfire-nvr/ui $  sudo apt-get update && sudo apt-get install yarn
Get:1 https://dl.yarnpkg.com/debian stable InRelease [17.1 kB]
Get:2 http://packages.microsoft.com/repos/code stable InRelease [10.4 kB]
Get:3 http://archive.raspberrypi.org/debian buster InRelease [32.8 kB]
Err:1 https://dl.yarnpkg.com/debian stable InRelease
  The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>
Get:4 http://packages.microsoft.com/repos/code stable/main armhf Packages [13.6 kB]
Get:5 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:6 http://packages.microsoft.com/repos/code stable/main amd64 Packages [13.0 kB]
Get:7 http://packages.microsoft.com/repos/code stable/main arm64 Packages [13.6 kB]
Get:8 http://archive.raspberrypi.org/debian buster/main armhf Packages [360 kB]
Get:9 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13.0 MB]
Reading package lists... Done
W: GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>
E: The repository 'https://dl.yarnpkg.com/debian stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
pi@raspberrypi:/usr/local/src/moonfire-nvr/ui $

I then went to yarn's site following the link above at: https://classic.yarnpkg.com/en/ and under the top heading there are three buttons "Getting Started", "Install Yarn" and "Migration to Yarn 2+".

I clicked "Getting Started" which takes me to https://classic.yarnpkg.com/en/docs/getting-started. At the Getting Started page, there is a button at the bottom right "Installation". Clicking "Installation" takes you to https://classic.yarnpkg.com/en/docs/install#windows-stable where there is a yellow box warning stating "These instruction only cover Yarn versions prior to 2.0 Those versions entered maintenance mode in January 2020..."

After my experience of being in February 2021 in an older version of Rust installed June 2020 that is now incompatible, I become concerned I might be headed down the wrong path for Yarn given Yarn's warning about versions under 2.0 being in "maintenance mode."

scottlamb commented 3 years ago

Thanks for asking. I somehow missed that there was a Yarn 2.0 and am still on "Classic Yarn". Sounds like I need to get off it (either to Yarn 2.0 or switch to npm) but Yarn 1.22.5 should work today.

scottlamb commented 3 years ago

and I think the bad signature thing will be fixed by https://classic.yarnpkg.com/en/docs/install#debian-stable here:

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

Maybe I should just switch to npm to avoid the extra step of installing yarn. When I first chose yarn it was a lot better than npm, but I think npm has caught up...

scottlamb commented 3 years ago

and I think the bad signature thing will be fixed by https://classic.yarnpkg.com/en/docs/install#debian-stable here:

Actually, no, I'm getting the same error when doing a fresh docker build. I think the yarn people just switched signatures or something? Strange!

jlpoolen commented 3 years ago

A perspective: In Gentoo, npm is frowned upon because of the security risk. I have npm installed on some machines, but I do so knowing I have a potential vector when it nilly willy downloads an assortment of packages.

On Fri, Feb 12, 2021 at 8:15 AM Scott Lamb notifications@github.com wrote:

and I think the bad signature thing will be fixed by https://classic.yarnpkg.com/en/docs/install#debian-stable here:

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

Maybe I should just switch to npm to avoid the extra step of installing yarn. When I first chose yarn it was a lot better than npm, but I think npm has caught up...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/scottlamb/moonfire-nvr/issues/110#issuecomment-778289954, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXP4KNRLY6HSN7WUNF3E3S6VH3JANCNFSM4XQ4YPEA .

-- John L. Poole

707-812-1323 jlpoole56@gmail.com

jlpoolen commented 3 years ago

And when you go to Yarn's site, I was unable in a minute or two to find a way to contact somebody about their problem of an invalid signature.

On Fri, Feb 12, 2021 at 8:26 AM Scott Lamb notifications@github.com wrote:

Actually, no, I'm getting the same error when doing a fresh docker build. I think the yarn people just switched signatures or something? Strange!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/scottlamb/moonfire-nvr/issues/110#issuecomment-778296093, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXP4O56WTURCXEMZJNKL3S6VJDTANCNFSM4XQ4YPEA .

-- John L. Poole

707-812-1323 jlpoole56@gmail.com

scottlamb commented 3 years ago

A perspective: In Gentoo, npm is frowned upon because of the security risk. I have npm installed on some machines, but I do so knowing I have a potential vector when it nilly willy downloads an assortment of packages.

Is this still true? IIRC npm used to not support a lockfile, which was one of yarn's original selling points. Now I believe npm's package-lock.json is equivalent to yarn's yarn.lock. Or maybe I'm misunderstanding the argument; can you point me to some Gentoo guidance about that?

jlpoolen commented 3 years ago

I guess this may no longer be true. I do not actively monitor the Gentoo Forum now, but several years ago you could not even find nodejs in the regular packages, one had to "unmask" node. I just checked now and there exist several Node packages in the standard package offering for AMD64. Also, recent topics in the forums suggest many users of Node.

I recall in the last 2 or 3 years the major security breach of the NPM where some package was made malicious by a developer that inherited ownership. It brought to light the vulnerability of the package system and underscored, to me, the danger.

Sorry, I just remember thinking I better not ask questions about node.js in the Gentoo Forum because of the feeling, then, that it was a major security problem. Same with PHP... though, we have demonstrated my assessment of Gentoo perspectives is out of date.

Also, outside of this topic, I sent an email to Daniel15 (Daniel Lo Nigro) about the signature problem, he looked to be the best contact for the yarn project.

scottlamb commented 3 years ago

So the NPM package ecosystem has many packages, with occasional problems like the (alarming) event-stream vulnerability or the (mostly just embarrassing) left-pad incident. It's impractical to avoid this ecosystem and do "modern Javascript development" with frameworks like React. Despite the name, the NPM ecosystem isn't just used by the NPM package manager; Yarn uses the same one.

Lockfiles mitigate problems somewhat by ensuring that the versions of dependencies which folks install match ones that I've specified (so if a dependency does a malicious npm publish, it's not immediately used by fresh builds of Moonfire NVR). Now that NPM supports lockfiles like Yarn, I think the two are equivalent security-wise.

In practice I don't carefully vet dependencies every time I update the lockfile, but I also generally only depend on mainstream/popular NPM packages, so if Moonfire NVR is affected by malware, many other things likely are too, and it'll be in the news. I also get automated notifications from github of potential security problems of NPM dependencies in my lockfile. (So far I believe all the vulnerabilities have been irrelevant to how I use the package, but I still get notified.)

(In concept all of this applies to the cargo registry used for Rust packages, too.)

I'm a little annoyed with yarn right now:

I think it'll be easier if I just switch to npm.

jlpoolen commented 3 years ago

You are wise to look into this carefully.

With the prospect of Moonfire-nvr handling what could be highly confidential information, e.g. videos of private areas, you want to be able to assure your users that all security concerns have been addressed. This is especially so in the backdrop of allegations that surveillance cameras have back-doors installed by manufacturers of inexpensive, e.g. $60, cameras.

What I like about Gentoo is that the leaders and prime movers there are fervent in their monitoring of security vulnerabilities. and making decisions to exclude from the Gentoo mainstream package system newer technologies whose security is of the "I'll rely on someone else to alert me of a problem." While a Gentoo user can make a decision to "unmask" a package, at least they do so having to make an edit in their configuration files acknowledging within their own system that they decided to take the risk. I've done this, especially on development servers, when I want to test new and exciting projects within a controlled environment.

Moonfire-nvr will undoubtely end up being used by people who want the easiest way to install it which may mean some sort of binary deployment. With that in mind, rigorous assessment of what goes into that binary is warranted by someone... which for the moment, is you, Scott.

Thank you.