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 rle...@codelibre.net (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 modes...@vainius.eu 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?
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 rle...@codelibre.net (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 rle...@debian.org
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: Bug#607945: sbuild: can haz I entropy?
Roger Leigh rle...@codelibre.net (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?
On Thu, Dec 30, 2010 at 07:24:20PM +0100, Cyril Brulebois wrote: Roger Leigh rle...@codelibre.net (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
