aptly version 1.5.0 not prompting for password during publish and ingoring -passphrase and -passphrase-file

[chindokae]

When trying to publish a large repo with multiple components, aptly fails to prompt for a password and fails with :"No Secret Key". It does not time out waiting on the password, it fails instantly.

Detailed Description

If I try a large publish like the one below, it fails to prompt for a password and then fails immediately on completion of the metadata creation tasks with a "No Secret Key" error.

aptly publish snapshot -component=main,universe,multiverse focal-main focal-universe focal-multiverse ubuntu

If I publish a simple and small snapshot like docker for focal it prompts for a password and succeeds.

Always works, always prompts for password: aptly publish snapshot docker-stable-snapshot

Only works if I have previously published docker and probably cached the password, never prompts for password: aptly publish snapshot -component=main,universe,multiverse focal-security-main focal-security-universe focal-security-multiverse ubuntu

Specifying the key and passphrase has no effect. Since it is picking up the default key correctly I can omit it from the command with no adverse effects. Provider is gpg2, it's the only one that works at all.

The following commands do not result in a prompt for password. They never use the file or the passphrase, quoted or not.

aptly publish snapshot -passphrase-file="/root/.password.txt" -gpg-key="1234B2C8A1234AB0A" -component=main,universe,multiverse focal-security-main focal-security-universe focal-security-multiverse ubuntu

aptly publish snapshot -batch -passphrase="password" -gpg-key="1234B2C8A1234AB0A" -component=main,universe,multiverse focal-security-main focal-security-universe focal-security-multiverse ubuntu

I've tried countless permutations of that command and none of them have ever used the passphrase-file or the passphrase. I have two additional repos for security and updates, they behave the same way.

The only way I've gotten this to work was by increasing gpg cache times and publishing the docker repo first, presumably caching my gpg credentials.

Request: Fix the code so that it works with -passphrase and --passphrase-file with gpg v2 and if those are not specified and gpg credentials are not cached, prompt for the password.

Your Environment

Linux focal.home.local 5.15.0-76-generic #83~20.04.1-Ubuntu SMP Wed Jun 21 20:23:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

aptly version: '1.5.0'

All patches current as of this posting.

gpg --version gpg (GnuPG) 2.2.19 libgcrypt 1.8.5

cat ~/.gnupg/gpg-agent.conf

set default cache time-to-live to 15 minutes

default-cache-ttl 7200

set max cache time-to-live to 1 hour

max-cache-ttl 7200

[yanzixiang]

up,up,same here.

[ydewinte]

same issue

[chindokae]

It's been over a year since I posted this and the issue has not changed. Not sure what it takes to get this tagged as a bug but it sure looks like one to me.

[neolynx]

Hi @chindokae, @ydewinte,

thanks for reporting and sorry for the delay. due to the circumstances, we are currently working on even older issues. but we will get through all of them eventually :)

I am not sure this is still a bug on master. As an example, the following works on Debian with latest CI release (took about 10min to publish, passphrase used from file):

$ aptly publish snapshot -batch -gpg-key=key@email -passphrase-file=/path/to/gpg/passphrase/file -distribution=noble test-merge-2 test-publish
Loading packages...
Generating metadata files and linking package files...
Finalizing metadata files...
Signing file 'Release' with gpg, please enter your passphrase when prompted:
Clearsigning file 'Release' with gpg, please enter your passphrase when prompted:

Snapshot test-merge-2 has been successfully published.

Changing gpg cache times should not be needed, as no agent should be involved. However, depending on how gpg is configured by default, this could vary.

Could you try with latest CI build ? Please post the commands and also the output of aptly...

aptly uses the keyring trustedkeys.gpg, sometimes it helped to recreate that.

[chindokae]

I did not see any release or tag for latest CI release and master looks like 1.5.0 but I cloned and built it anyway, It now says:

aptly version: 1.5.0+198+g37a9fbe5

I'm not sure if "+198+g37a9fbe5" denotes an actual revision or if it is just a build artifact.

I did manage to get one good publish out of it but two subsequent publish attempts failed with bad password warnings.

I made no changes between runs, I just went to the next snapshot.

I don't know if it matters or not but the password file has an extra linefeed (0A) character at the end of the password string that should not be there. The file size changed at what I believe was the time I attempted to publish a snapshot.

I normally edit with vim and I have not seen it randomly adding extra linefeeds to files, changing the file size. I don't know whether aptly considers non-printable characters to be part of a password, but if it does, that could be the reason for the otherwise inexplicable bad password error.

Would aptly consider the altered file to contain a bad password and could it have altered the file itself?

[neolynx]

Hi @chindokae,

how do you invoke aptly ? via API ?

by password file you mean the one provided with the -passphrase-file= argument ?

could you please share some examples to reproduce ?