Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Alkis Georgopoulos]

After creating a chroot with:
1) debootstrap
2) debootstrap --variant=minbase
and installing ltsp-client-core in both of them, I got the following
results:

1) stretch-minbase-ltsp: 314M
2) stretch-normal-ltsp: 350M

The difference is small, mainly due to apt-utils, bsdmainutils, cron,
debconf-i18n, gnupg, ifupdown, iptables, isc-dhcp-client, logrotate,
nano, rsyslog, vim-tiny, wget, whiptale.

Some of those are even useful for minimal ltsp chroots as well.

Regardless of actions taken in other packages, maybe LTSP should stop
using --variant=minbase?

Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Daniel Kahn Gillmor]

[ adding pkg-gnupg-maint to the cc list ]

On Mon 2016-07-18 17:19:13 +0200, Holger Levsen  wrote:
> On Mon, Jul 18, 2016 at 08:02:40AM -0700, Vagrant Cascadian wrote:
>> At any rate, Wolfgang Schweer confirmed that adding it to the
>> debootstrap includes worked around the issue, although then we'd have
>> the problem of deciding on gnupg vs. gnupg2, and at some point gnupg
>> will disappear.
>
> I believe we should stop using gnupg and switch to gnupg2 in sid, cc:
> Daniel for input on this.

the gnupg2 source package in experimental provides the "gnupg" binary
package, while the "gnupg" binary package in experimental provides a
"gnupg1" binary package.  confusing, right? :P  

I will probably rename the gnupg source package to "gnupg1" to make the
names slightly less confusing before it lands in experimental.

But the point is that the "gnupg" binary package will continue to exist,
so if you have to pick one you should pick it :)

But i think that the better solution is to avoid using apt-key in the
way you're talking about using it.  It's much better to place the
OpenPGP binary format key that you care about directly into
/etc/apt/trusted.gpg.d/$FOO

If you've got it in ascii-armored format and aren't sure how to decode
it, you should be able to do that with a short awk | base64 -d pipeline:

  awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d 

hth,

   --dkg


signature.asc
Description: PGP signature

Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Alkis Georgopoulos]

So it sounds like something run apt with --no-install-recommends, right?
I don't think that's LTSP, could it be Debian Edu?
Maybe it could just drop the --no-install-recommends parameter?

Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Holger Levsen]

On Sun, Jul 17, 2016 at 09:39:22AM -0700, Vagrant Cascadian wrote:
> No, the problem is inside the LTSP chroot, before any LTSP packages are
> installed in the chroot, so installing packages on the server won't
> help. It needs to be handled in the ltsp-build-client debootstrap call
> or possibly by dropping use of apt-key and copying appropriate key files
> into /etc/apt/trusted.gpg.d/.

ok, cool, then we'll wait for a fix in the LTSP packages! :)

thanks for your continous work on LTSP!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Wolfgang Schweer]

On Sun, Jul 17, 2016 at 09:35:45AM -0700, Vagrant Cascadian wrote:
> I *think* it needs to be added to debootstrap's --include= to ensure it
> is installed early enough (or setting DEBOOTSTRAP_INCLDUE=gnupg or
> DEBOOTSTRAP_INCLUDE=gnupg2).
 
Adding a line containing 'INCLUDE=gnupg2' as first line in 
010-debootstrap seems to work.

Wolfgang


signature.asc
Description: Digital signature

Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Vagrant Cascadian]

On 2016-07-17, Holger Levsen wrote:
> do you agree that ltsp-server should recommend (or depend) gnupg2|gnupg
> or do you think that education-thin-client-server should have that
> recommends/depends as we're telling ltsp-server to use apt-key?

No, the problem is inside the LTSP chroot, before any LTSP packages are
installed in the chroot, so installing packages on the server won't
help. It needs to be handled in the ltsp-build-client debootstrap call
or possibly by dropping use of apt-key and copying appropriate key files
into /etc/apt/trusted.gpg.d/.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Vagrant Cascadian]

On 2016-07-15, Wolfgang Schweer  wrote:
> while testing Debian Edu stretch I noticed that the LTSP chroot failed 
> to build.
>
> This is most probably caused by a recent change to apt, see: #830696
>
> I faced this error too:
> Error: gnupg or gnupg2 do not seem to be installed,
> Error: but apt-key requires gnupg or gnupg2 for this operation.

Thanks for the report!


> Adding gnupg or gnupg2 to the early packages list was to no avail.
> But after commenting out the apt-key call the chroot was built.
>
> Not quite sure, but I guess gnupg2 | gnupg might be needed as 
> Pre-Depends of ltsp-client.

No, ltsp-build-client on the server calls apt-keys within the chroot
before installing ltsp-client* (during the same pass that early-packages
is installed), so this needs to happen earlier.

I *think* it needs to be added to debootstrap's --include= to ensure it
is installed early enough (or setting DEBOOTSTRAP_INCLDUE=gnupg or
DEBOOTSTRAP_INCLUDE=gnupg2).

Alternately, maybe dropping the appropriate keys into
/etc/apt/trusted.gpg.d/ would work without requiring installing
additional software (need to verify that it doesn't downgrade to
accepting unsigned repositories in this case); though that will likely
break support for older releases.


live well,
  vagrant


signature.asc
Description: PGP signature