GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn Packaging <yarn@dan.cx>

[tommym9]

Hi,

Doing a ddev start this morning and I've bumped into an issue that I'm struggling to fix.

Reading package lists...
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.
', stderr='Building db
Building web
Service 'web' failed to build : The command '/bin/sh -c apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y -o Dpkg::Options::="--force-confold" --no-install-recommends --no-install-suggests build-essential' returned a non-zero code: 100'

A Google of this and I've seen there is a fix: yarnpkg/yarn#7866

My problem is I'm not so hot on docker so I'm struggling to figure out where this fix needs to go.

Cheers

Tom

DDEV version: 1.16.5
Docker Dekstop: 3.0.4 (updated to 3.1.0 and no change)
MacBook Pro: Catalina 10.15.7

[carstendietrich]

Can confirm that using webimage_extra_packages: / apt update in general lead to this issue for v1.16.5 as well as v1.17.0-alpha3 on MacOS

[tommym9]

I found a fix by adding

#temp gpg error fix
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
#temp gpg error fix
RUN apt-get update

to my web-build/Dockerfile

@carstendietrich any chance you could post a code snippet for your fix? Looks a bit cleaner than mine!

[hctom]

Same here, quickfix suggested by @tommym9 solves the problem for now. Hope there will be an official fix/release for this soon.

[carstendietrich]

@tommym9 in my project I don't have any complex setup therefore I only rely on the webimage_extra_packages option in the .ddev/config.yaml for adding additional apt packages. Therefore I don't have a dedicated web-build/Dockerfile since adding that will disable the webimage_extra_packages setting.

So as a temporary fix I pretty much did the same as you, only that I needed to add the web-build/Dockerfile manually and add the stuff that I had previously specified in webimage_extra_packages.

So my web-build/Dockerfile now looks like this:

ARG BASE_IMAGE
FROM $BASE_IMAGE

# fix yarn key
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -

# install packages previously set in webimage_extra_packages
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y -o Dpkg::Options::="--force-confold" --no-install-recommends --no-install-suggests php7.1-mcrypt php7.1-tidy make redis-tools

Guess now we are waiting for an updated web-base image that already contains the latest yarn key.

[rfay]

It's amazing that this happens every Feb 1. This is yarnpkg/yarn#6865 (and yarnpkg/yarn#7866 as mentioned above) and it just seems to be every single year.

I guess I'll need to do a release. The two answers here are perfect.

[carstendietrich]

It's amazing that this happens every Feb 1. This is yarnpkg/yarn#6865 and it just seems to be every single year.

I guess I'll need to do a release. The two answers here are perfect.

Maybe switch the way Yarn is installed. According to docs it is recommended to use NPM for installing Yarn globally: https://yarnpkg.com/getting-started/install

That could avoid the yearly key issue 😁

[rfay]

I can definitely switch to the npm approach. Will that break people?

[rfay]

The current shipping/installed version of yarn in the ddev web container is 1.22.5 - the npm approach will switch to yarn v2.

[rfay]

I note that the problem in this issue probably only affects people who one way or another do an apt-get update in their project, either via webimage_extra_packages or a custom Dockerfile. So it won't affect all ddev users right away.

[carstendietrich]

As far as I understand the docs this shouldn't be breaking. If you install yarn globally via NPM you get version 1.22.10..

If you want to use yarn v2 and all later versions you need to actively switch on a per-project basis via: yarn set version berry (this will set v2 for the project folder you're in)

Using a single package manager across your system has always been a problem. To be stable, installs need to be run with the same package manager version across environments, otherwise there's a risk we introduce accidental breaking changes between versions - after all, that's why the concept of lockfile was introduced in the first place! And with Yarn being in a sense your very first project dependency, it should make sense to "lock it" as well.

For this reason, Yarn 2 and later are meant to be managed on a by-project basis.

https://yarnpkg.com/getting-started/install

[rfay]

Thanks, yes, just installing via npm gets v1; I missed that part. I'll do a new v1.16.6 release and also fix it for v1.17 in drud/ddev-images#43

[Daniel15]

It's amazing that this happens every Feb 1. This is yarnpkg/yarn#6865 (and yarnpkg/yarn#7866 as mentioned above) and it just seems to be every single year.

I've been meaning to fix it so that the Yarn key can be automatically renewed (eg by packaging it in a Debian package that the yarn package depends on), but never got around to it, and so far people have only been willing to complain about it but not actually spend time helping to improve it 🙂

[rfay]

Thanks @Daniel15 - I'm changing this to use the npm installation technique. That will solve everything right?

[rfay]

Thanks so much for reporting this issue @tommym9 and @carstendietrich - ddev v1.16.6 and v1.17.0-alpha4 are building right now and will be available shortly. Please check to make sure they resolve your issues.

[Daniel15]

I'm changing this to use the npm installation technique. That will solve everything right?

Sure.

It's only an issue with GPG signing. npm repositories are not signed at all, so there's no problem, in the same way that you can solve the issue of losing or breaking your keys by removing the lock from your front door :)