Yarn: Figure out why Debian repo build is failing

[Daniel15]

For some reason, signing the repo is failing

+ aptly -config=./.aptly.conf repo add yarn /tmp/tmp.rU06DB21NP/yarn_1.9.2_all.deb
Loading packages...
[+] yarn_1.9.2-1_all added
+ aptly -config=./.aptly.conf publish update -gpg-key=E074D16EB6FF4DE3 stableLoading packages...
Generating metadata files and linking package files...
Finalizing metadata files...
Signing file 'Release' with gpg, please enter your passphrase when prompted:
gpg: skipped "E074D16EB6FF4DE3": secret key not available
gpg: signing failed: secret key not available
ERROR: unable to publish: unable to detached sign file: exit status 2

However, signing with the master key (rather than a subkey) works fine.

[Daniel15]

I'll look at this once I'm back from vacation, this issue is just to remind me about it.

[DanielRuf]

It seems like the keypair is not complete (secret key not available).
Did you enter the passphrase?
It's not directly related to yarn.

[Daniel15]

@DanielRuf It's definitely available though, which is why I'm confused:

12:39 daniel@vps03 /home/daniel
% gpg --edit-key 72ECF46A56B4AD39C907BBB71646B01B86E50310
gpg (GnuPG) 2.2.8; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/1646B01B86E50310
     created: 2016-10-05  expires: never       usage: SC
     trust: ultimate      validity: ultimate
ssb  rsa4096/02820C39D50AF136
     created: 2016-10-05  expires: never       usage: E
ssb  rsa4096/D101F7899D41F3C3
     created: 2016-10-05  expired: 2017-10-05  usage: S
ssb  rsa4096/46C2130DFD2497F5
     created: 2016-10-30  expires: 2019-01-01  usage: S
ssb  rsa4096/E074D16EB6FF4DE3
     created: 2017-09-10  expires: 2019-01-01  usage: S
[ultimate] (1). Yarn Packaging <[email protected]>

[DanielRuf]

related issues
https://github.com/aptly-dev/aptly/issues/204
https://github.com/aptly-dev/aptly/issues/689#issuecomment-354013636
https://lists.gnupg.org/pipermail/gnupg-users/2010-March/038574.html

I guess it is an issue with the gpg-agent (chown / permissions, gpg version, wrong keyring, ...) or something else.

What happens if you do it manually with gpg gpg --default-key E074D16EB6FF4DE3 --output release.sig --sign release and try to increase the vebosity level?

[Daniel15]

Hmm, manually invoking gpg works fine.

20:33 daniel@vps03 /tmp/testsign
% gpg --default-key E074D16EB6FF4DE3 --sign hello.txt
gpg: using "E074D16EB6FF4DE3" as default secret key for signing

20:33 daniel@vps03 /tmp/testsign
% ls
hello.txt  hello.txt.gpg

20:33 daniel@vps03 /tmp/testsign
% gpg --verify hello.txt.gpg
gpg: Signature made Wed 01 Aug 2018 08:33:43 PM PDT
gpg:                using RSA key E21930C4D0A4AA4618581F7AE074D16EB6FF4DE3
gpg: Good signature from "Yarn Packaging <[email protected]>" [ultimate]

I'd like to see exactly what gpg command Aptly is using, but I can't find a verbose flag for it...

[Daniel15]

Ahh I think I worked it out: https://www.aptly.info/doc/feature/pgp-providers/

Aptly at this time only supports GNUPG 1.x for server-side use.

It looks like GPG 1.x doesn't have the secret key for some reason:

20:40 daniel@vps03 /tmp/testsign
% gpg1 --default-key E074D16EB6FF4DE3 --sign hello.txt
gpg: no default secret key: secret key not available
gpg: signing failed: secret key not available

Maybe they use different keychains. I'll figure out what's up.

[DanielRuf]

Maybe they use different keychains

Exactly, this is often the case.
At least I had to import my keypair for both on one of my computers. Sometimes we can also change the used gpg version and client to the other.

[DanielRuf]

Let me know if I can help here somehow or should search for the needed commands. I've done it about a few years ago and did not need it since then (changing the used gpg client and syncing the keyrings / keychains).

[Daniel15]

Importing the secret get from GPG v2 to v1 didn't seem to do anything:

22:27 daniel@vps03 /home/daniel
% gpg --export-secret-keys E074D16EB6FF4DE3 | gpg1 --import
gpg: key 86E50310: already in secret keyring
gpg: Total number processed: 1
gpg:       secret keys read: 1
gpg:  secret keys unchanged: 1

22:28 daniel@vps03 /home/daniel
% gpg --export E074D16EB6FF4DE3  | gpg1 --import
gpg: key 86E50310: "Yarn Packaging <[email protected]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

But signing with gpg1 still doesn't work:

22:28 daniel@vps03 /tmp/testsign
% gpg1 --default-key E074D16EB6FF4DE3 --sign hello.txt
gpg: no default secret key: secret key not available
gpg: signing failed: secret key not available

Hmm.

Versions:

22:29 daniel@vps03 /tmp/testsign
% gpg --version
gpg (GnuPG) 2.2.8
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/daniel/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
22:29 daniel@vps03 /tmp/testsign
% gpg1 --version
gpg (GnuPG) 1.4.23
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

[Daniel15]

Found this on SuperUser:

but be aware GnuPG cannot merge secret subkeys but starting with GnuPG 2.1 -- so if you change anything with the subkeys in GnuPG 2.1, you'd have to delete the whole key in GnuPG 1 before importing

(https://superuser.com/a/1098778)

So I just deleted and re-imported the key:

22:32 daniel@vps03 /tmp/testsign
% gpg --export-secret-keys E074D16EB6FF4DE3 > ~/yarnkey

22:33 daniel@vps03 /tmp/testsign
% gpg1 --delete-secret-keys 86E50310
gpg (GnuPG) 1.4.23; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


sec  4096R/86E50310 2016-10-05 Yarn Packaging <[email protected]>

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
22:33 daniel@vps03 /tmp/testsign
% gpg1 --delete-keys 86E50310

gpg (GnuPG) 1.4.23; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  4096R/86E50310 2016-10-05 Yarn Packaging <[email protected]>

Delete this key from the keyring? (y/N) y

22:33 daniel@vps03 /tmp/testsign
% gpg1 --import ~/yarnkey
gpg: key 86E50310: secret key imported
gpg: key 86E50310: public key "Yarn Packaging <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

Now it works!

[Daniel15]

I just hit this again... I'm glad I documented the steps I followed last time.

[rgaufman]

What happened to key 86E50310? - it seems it is no longer working?

[Daniel15]

86E50310 is the old key that expired on 1st January 2019. We recently switched to a new key that expires in 2020

[DanielRuf]

Why was it not extended instead of creating a new key or is this the normal process?

[Daniel15]

I think it's a usual process to totally change the key rather than just extending the old key. See https://crypto.stackexchange.com/a/41814 for example:

say it takes X months of computation (expected value given your threat model) to crack a key, and you rotate your signing key every X−1 months and revoke the old one, then by the time an attacker has cracked the key, any new signatures produced by the attacker will either be A) rejected by clients because of key expiry, or B) back-dated to before the key revocation (which should also raise warning in clients).

[DanielRuf]

With 4096 or better the keys will be secure for a very long time. This is highly unlikely imo.