Bug#607945: [buildd-tools-devel] Bug#607945: Bug#607945: Bug#607945: sbuild: can haz I entropy?
Hello, On ketvirtadienis 30 Gruodis 2010 20:33:48 Roger Leigh wrote: > On Thu, Dec 30, 2010 at 07:24:20PM +0100, Cyril Brulebois wrote: > > Roger Leigh (30/12/2010): > > > > Per host. It's stored in /var/lib/sbuild/apt-keys . > > > > > > Note that if there's a reason to do it per-chroot, we can do that. > > > I couldn't envisage any security issues in sharing this key between > > > chroots, but if there are it's a simple change. > > > > Was just wondering whether this might make sense to move key creation > > to sbuild's install time (openssh-server's style). Might be, if/when > > the default resolver gets changed. > > > > (“make sense” as in “can be thought of if it's per-host, and not if > > it's per-chroot”; other considerations left aside.) > > I did consider triggering this in the postinst. I was concerned that > this could break package installation on systems with scarce entropy > by blocking package installation indefinitely. Since this is currently > an optional feature, I opted to allow generation when required. > > After squeeze, I'd like to look at moving to the apt resolver (having > more consistent/predicatable behaviour than aptitude). Oh, that's a myth with deep history apparently. Could you point me to a single case where (modern) aptitude resolver failed recently? With current safeguards in place, it should be very reliable and thanks to it, experimental is no longer a PITA making many people (including me) happy. As long as apt-get does not consider dependencies from non-default sources, it won't be an option for non-unstable buildds. And apt-get resolver is not configurable at all (don't know about that new stuff in apt/experimental though). P.S. This does not mean I advocate aptitude as default resolver. I'm just acting a role of mythbuster, someone has to :) -- Modestas Vainius signature.asc Description: This is a digitally signed message part.
Bug#607945: [buildd-tools-devel] Bug#607945: Bug#607945: Bug#607945: sbuild: can haz I entropy?
On Thu, Dec 30, 2010 at 07:24:20PM +0100, Cyril Brulebois wrote: > Roger Leigh (30/12/2010): > > > Per host. It's stored in /var/lib/sbuild/apt-keys . > > > > Note that if there's a reason to do it per-chroot, we can do that. > > I couldn't envisage any security issues in sharing this key between > > chroots, but if there are it's a simple change. > > Was just wondering whether this might make sense to move key creation > to sbuild's install time (openssh-server's style). Might be, if/when > the default resolver gets changed. > > (“make sense” as in “can be thought of if it's per-host, and not if > it's per-chroot”; other considerations left aside.) I did consider triggering this in the postinst. I was concerned that this could break package installation on systems with scarce entropy by blocking package installation indefinitely. Since this is currently an optional feature, I opted to allow generation when required. After squeeze, I'd like to look at moving to the apt resolver (having more consistent/predicatable behaviour than aptitude). If we do make this change, then we can consider generating at install time given that it's required for sbuild to work. We now have tested the apt resolver quite extensively and the main blocker is making sure it behaves completely consistently for a given package set and base chroot to ensure reproducibility. Now we have clean cloned chroots for building, the main issue of inconsistent builds in dirty chroots is now basically a non-issue providing we use cloned chroot across the board. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: Bug#607945: Bug#607945: sbuild: can haz I entropy?
Roger Leigh (30/12/2010): > > Per host. It's stored in /var/lib/sbuild/apt-keys . > > Note that if there's a reason to do it per-chroot, we can do that. > I couldn't envisage any security issues in sharing this key between > chroots, but if there are it's a simple change. Was just wondering whether this might make sense to move key creation to sbuild's install time (openssh-server's style). Might be, if/when the default resolver gets changed. (“make sense” as in “can be thought of if it's per-host, and not if it's per-chroot”; other considerations left aside.) > > Also, as discussed on IRC, we will solve this by bailing out with > > an error when the key is absent. This will require the user to > > generate a key. > > Fixed in commit fb790792. Is this OK for you? Not tested yet, but sounds sensible. KiBi. signature.asc Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: Bug#607945: Bug#607945: sbuild: can haz I entropy?
tags 607945 + patch fixed-upstream pending
thanks
On Thu, Dec 30, 2010 at 05:39:26PM +, Roger Leigh wrote:
> On Thu, Dec 30, 2010 at 06:21:31PM +0100, Cyril Brulebois wrote:
> > Roger Leigh (29/12/2010):
> > > This is a one-time only event. Once the key is generated (which you
> > > can do with "sbuild-update -k" on another system or outside a
> > > package build at your leisure) the same key will be used for all
> > > subsequent builds.
> >
> > One-time.. per host? Or per chroot?
>
> Per host. It's stored in /var/lib/sbuild/apt-keys .
Note that if there's a reason to do it per-chroot, we can do that. I
couldn't envisage any security issues in sharing this key between
chroots, but if there are it's a simple change.
> Also, as discussed on IRC, we will solve this by bailing out with an
> error when the key is absent. This will require the user to generate
> a key.
Fixed in commit fb790792. Is this OK for you?
Regards,
Roger
commit fb790792a9433d469fa808f6613bdc0bf1f3ee21
Author: Roger Leigh
Date: Thu Dec 30 17:53:15 2010 +
Sbuild::ResolverBase: Don't automatically generate archive signing key
If the local archive signing key is not present, do not automatically
generate it. This can cause issues on systems with scarce entropy.
Print an error message plus instructions on how to generate the key.
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index ca2052b..16a6356 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -758,17 +758,15 @@ sub generate_keys {
return 1;
}
-my $host = $self->get('Host');
-
-$self->log("Generating GPG local archive signing key...\n");
-if (Sbuild::ChrootSetup::generate_keys($host, $self->get('Config'))) {
- # Since apt-distupgrade was requested specifically, fail on
- # error when not in buildd mode.
- $self->log("Generating gpg keys failed\n");
- return 0;
-}
-
-return 1;
+$self->log_error("Local archive GPG signing key not found\n");
+$self->log_info("Please generate a key with 'sbuild-update --keygen'\n");
+$self->log_info("Note that on machines with scarce entropy, you may wish ".
+ "to generate the key with this command on another machine ".
+ "and copy the public and private keypair to '" .
+ $self->get_conf('SBUILD_BUILD_DEPENDS_PUBLIC_KEY')
+ ."' and '".
+ $self->get_conf('SBUILD_BUILD_DEPENDS_SECRET_KEY') ."'\n");
+return 0;
}
# Function that runs apt-ftparchive
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: Bug#607945: sbuild: can haz I entropy?
On Thu, Dec 30, 2010 at 06:21:31PM +0100, Cyril Brulebois wrote: > Roger Leigh (29/12/2010): > > This is a one-time only event. Once the key is generated (which you > > can do with "sbuild-update -k" on another system or outside a > > package build at your leisure) the same key will be used for all > > subsequent builds. > > One-time.. per host? Or per chroot? Per host. It's stored in /var/lib/sbuild/apt-keys . > > The current strategy is to allow you to generate your own key and > > put it in place. If you haven't done that, it will autogenerate one > > the first time it's needed. For buildds, you'll probably want to > > generate one elsewhere and copy it cover. Note this is in the > > release notes (NEWS.gz) for release 0.60.6. > > Which apt-listchanges doesn't show, so.. It's in the upstream changelog and NEWS. > > If you have any thoughts on how we can do this better, that would be > > great. apt and aptitude want the local archive signing, so we do it > > for that. If using the "internal" resolver, no key is needed. > > Since you changed the default (which is another story, sigh), I'm not > using the internal resolver anymore. As mentioned on IRC, the default has *not* been changed. Also, as discussed on IRC, we will solve this by bailing out with an error when the key is absent. This will require the user to generate a key. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: sbuild: can haz I entropy?
severity 607945 important thanks Cyril Brulebois (30/12/2010): > Since you changed the default (which is another story, sigh), I'm > not using the internal resolver anymore. Sorry, that's untrue. I thought I had all reinstalled after having purged the packages, but there was some ~/.sbuildrc in the way. Downgrading severity accordingly. KiBi. signature.asc Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: sbuild: can haz I entropy?
Roger Leigh (29/12/2010): > This is a one-time only event. Once the key is generated (which you > can do with "sbuild-update -k" on another system or outside a > package build at your leisure) the same key will be used for all > subsequent builds. One-time.. per host? Or per chroot? > The current strategy is to allow you to generate your own key and > put it in place. If you haven't done that, it will autogenerate one > the first time it's needed. For buildds, you'll probably want to > generate one elsewhere and copy it cover. Note this is in the > release notes (NEWS.gz) for release 0.60.6. Which apt-listchanges doesn't show, so.. > If you have any thoughts on how we can do this better, that would be > great. apt and aptitude want the local archive signing, so we do it > for that. If using the "internal" resolver, no key is needed. Since you changed the default (which is another story, sigh), I'm not using the internal resolver anymore. KiBi. signature.asc Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: Bug#607945: sbuild: can haz I entropy?
On Wed, Dec 29, 2010 at 03:52:59PM +, Roger Leigh wrote: > On Fri, Dec 24, 2010 at 08:56:31PM +0100, Cyril Brulebois wrote: > > Dear Santa Claus, > > > > can I haz entropy plz? sbuild seems to need it suddenly, which comes > > like a big unpleasant surprise: > > | Check arch > > | ── > > | > > | dpkg-deb: building package `sbuild-build-depends-core-dummy' in > > | `/tmp/resolver-PVdljw/apt_archive/sbuild-build-depends-core-dummy.deb'. > > | Generating GPG local archive signing key... > > | > > | Not enough random bytes available. Please do some other work to give > > | the OS a chance to collect more entropy! (Need 277 more bytes) > > > > It's a bit late in the Christmas gift release process, but hopefully > > you'll make it in time. > > Only just got back from the family, but I'll try for New Year! > > > This is a one-time only event. Once the key is generated (which you > can do with "sbuild-update -k" on another system or outside a > package build at your leisure) the same key will be used for all > subsequent builds. > > The current strategy is to allow you to generate your own key and > put it in place. If you haven't done that, it will autogenerate one > the first time it's needed. For buildds, you'll probably want to > generate one elsewhere and copy it cover. Note this is in the > release notes (NEWS.gz) for release 0.60.6. > > If you have any thoughts on how we can do this better, that would be > great. apt and aptitude want the local archive signing, so we do it > for that. If using the "internal" resolver, no key is needed. One alternative possibility would be to simply never autogenerate keys, and skip the build if a GPG key wasn't already present. This would then require the user to generate a key by hand with "sbuild-update -k". While this would prevent the entropy issues you ran into, it would inconvenience most users on whose systems the autogeneration works. In the interim, I've added a more prominent notice in sbuild 0.60.8; we notify the user much more clearly that GPG key generation is taking place. While this doesn't fix the problem, it does at least make it clearer as to what's going on. It's an unfortunate circumstance that requires this. The APT resolver won't work correctly unless installing the dependency package from an archive (or else it will consider removal of the dependency package as a valid solution), which requires us to set up a local archive. This then requires the archive to be signed or else we have security issues (APT::Get::AllowUnauthenticated=true would disable checking of all repos). If there's a way around this, I would definitely be happy to consider it. Ideally, apt-get would be as flexible as aptitude in installing the dummy package, but at the moment it isn't. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#607945: [buildd-tools-devel] Bug#607945: sbuild: can haz I entropy?
On Fri, Dec 24, 2010 at 08:56:31PM +0100, Cyril Brulebois wrote: > Dear Santa Claus, > > can I haz entropy plz? sbuild seems to need it suddenly, which comes > like a big unpleasant surprise: > | Check arch > | ── > | > | dpkg-deb: building package `sbuild-build-depends-core-dummy' in > | `/tmp/resolver-PVdljw/apt_archive/sbuild-build-depends-core-dummy.deb'. > | Generating GPG local archive signing key... > | > | Not enough random bytes available. Please do some other work to give > | the OS a chance to collect more entropy! (Need 277 more bytes) > > It's a bit late in the Christmas gift release process, but hopefully > you'll make it in time. Only just got back from the family, but I'll try for New Year! This is a one-time only event. Once the key is generated (which you can do with "sbuild-update -k" on another system or outside a package build at your leisure) the same key will be used for all subsequent builds. The current strategy is to allow you to generate your own key and put it in place. If you haven't done that, it will autogenerate one the first time it's needed. For buildds, you'll probably want to generate one elsewhere and copy it cover. Note this is in the release notes (NEWS.gz) for release 0.60.6. If you have any thoughts on how we can do this better, that would be great. apt and aptitude want the local archive signing, so we do it for that. If using the "internal" resolver, no key is needed. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#607945: sbuild: can haz I entropy?
Package: sbuild Version: 0.60.7-1 Severity: serious Justification: buildds usually lack mice to play with to generate entropy. Dear Santa Claus, can I haz entropy plz? sbuild seems to need it suddenly, which comes like a big unpleasant surprise: | Check arch | ── | | dpkg-deb: building package `sbuild-build-depends-core-dummy' in | `/tmp/resolver-PVdljw/apt_archive/sbuild-build-depends-core-dummy.deb'. | Generating GPG local archive signing key... | | Not enough random bytes available. Please do some other work to give | the OS a chance to collect more entropy! (Need 277 more bytes) It's a bit late in the Christmas gift release process, but hopefully you'll make it in time. Thank you! KiBi. -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sbuild depends on: ii adduser 3.112+nmu2 add and remove users and groups ii libsbuild-perl0.60.7-1 Tool for building Debian binary pa ii perl 5.10.1-16 Larry Wall's Practical Extraction ii perl-modules 5.10.1-16 Core Perl modules Versions of packages sbuild recommends: ii debootstrap 1.0.26 Bootstrap a basic Debian system ii fakeroot 1.14.5-1 Gives a fake root environment Versions of packages sbuild suggests: ii deborphan 1.7.28.3 program that can find unused packa ii wget 1.12-2.1 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
