Hi,
Quoting Guilhem Moulin (2016-09-10 00:04:19)
> #833547/#834898 have been fixed by adding a call to ‘gpgconf --kill
> gpg-agent’. I was wondering whether access to private key material from
> inside the chroot is required at all? Sbuild::ResolverBase reads
>
> # Sign the release file
> # This will only be done if the sbuild keys are present.
> # Once squeeze is not supported anymore, we want to never sign the
> # dummy repository anymore but instead make use of apt's support for
> # [trusted=yes] in wheezy and later.
> # On hosts that include apt 1.3~exp1 or newer (Debian squeeze or later)
> # the gnupg package will no longer be installed because apt doesn't depend
> # on it anymore.
>
> After installing sbuild on sid, the directory ‘/var/lib/sbuild/apt-keys’
> is left empty, thus sbuild doesn't sign the dummy Release file and apt
> trusts it regardless thanks to the [trusted=yes] option.
>
> However when *upgrading* sbuild from an older version, the key pair
> ‘/var/lib/sbuild/apt-keys/sbuild-key.{pub,sec}’, which was created for
> compatibility with apt <1.3~exp1, is still used for signing the Release
> file. This code path seems obsolete to me as squeeze reached end of LTS
> in February 2016. Furthermore since signing the dummy Release file is
> AFAICT currently the only reason why sbuild requires access to private
> key material (hence spawns a gpg-agent(1) process with GnuPG 2.1.x) from
> inside the chroot, removing ‘/var/lib/sbuild/apt-keys’ and
> ‘SBUILD_BUILD_DEPENDS_{SECRET|PUBLIC}_KEY’ should also remove the need
> for the ‘gpgconf --kill gpg-agent’ workaround.I do not see any bug here. You are just describing the current situation. Please describe the problem you are experiencing. Thanks! cheers, josch
signature.asc
Description: signature
