From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1bYovV-0001AH-QP for mharc-grub-devel@gnu.org; Sun, 14 Aug 2016 02:29:41 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYovS-00019w-Qw for grub-devel@gnu.org; Sun, 14 Aug 2016 02:29:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYovO-0001aG-Kb for grub-devel@gnu.org; Sun, 14 Aug 2016 02:29:37 -0400 Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:38532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYovO-0001aB-Dk for grub-devel@gnu.org; Sun, 14 Aug 2016 02:29:34 -0400 Received: by mail-wm0-x22a.google.com with SMTP id o80so47905892wme.1 for ; Sat, 13 Aug 2016 23:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=AmrTg/mwJutiWp59/1S1K5AWYqZhz39RB6yZQmwG/V0=; b=xs9ciAe8XPfVORqy+TYRd62ILLTd8SxH/QX+XZtcDaUEFsBZa0ppcHKA2np8IE/lBM KX5AAVbAf3wB+2qZ9/V1LJlTTm3Lf7uhaZRfs/xQo9OLpccd0XLtAzFrT48Nu+PtkOJR BXQAOhAqunAeLXVMs3UMWfQllOP4PMaRIQEkLOQK2k4dBA5NrLjhNze61+kpxT65Umu4 gf29JFeiTl1TEnpBP9BqhmS7d0xiiOPeGnrshBcWMAJdvjMVTKYeFuy4p/T6oYxGRVI9 Srtm1kRJ/AxNsboYtaFhiMzb/NcIiWe2WjVEE1vrbxvA2F2jU9J7YaX7AvDdqzgl7M2Z mtCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=AmrTg/mwJutiWp59/1S1K5AWYqZhz39RB6yZQmwG/V0=; b=k+Jdc9LZXU1//3q/2HpvsTb1GY1/71h1zm0OpSKP3lmP3L4JcRD1cLGqzHu6wH1RQC JC1Eo28bz3omqnB+FJtGnIPvV84Jj0ApVFhOPujjRBoyJGtXmvPzZ7B0wY7CPSbp+6OQ sqrxOEmrk4hqBR5l1uQPLpMYi8X2ojPsj9hOPpBoXOdD29HjSaYsrXHM56iQC810cBMb L8Pqv7onZF0N9e6c8B+aYEB0qLkfWXwV7ptlCoVoncm1EwQc0SJ3WWpe9m92BYJo+6IE Tuh/ToY41QKlGbWfpP6IDwPiUy/XDyJY00ywgfYsTwdJd2dXdQddTrZIw1LuVaqjabeu moPQ== X-Gm-Message-State: AEkoousV1NL9ygiI9ZBzl+8/0gZMONT2B4XHKjk3Jxq6Lk4LsLI6s0pnvp8TaUVQnXRtVw== X-Received: by 10.25.219.10 with SMTP id s10mr3956801lfg.101.1471156173363; Sat, 13 Aug 2016 23:29:33 -0700 (PDT) Received: from [192.168.1.43] (ppp109-252-91-231.pppoe.spdop.ru. [109.252.91.231]) by smtp.gmail.com with ESMTPSA id j64sm2287173lfb.31.2016.08.13.23.29.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Aug 2016 23:29:32 -0700 (PDT) Subject: Re: Do grub-mkrescue GPT GUIDs need more entropy than --fs-uuid gets ? To: grub-devel@gnu.org References: <8455587854707933842@scdbackup.webframe.org> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: Date: Sun, 14 Aug 2016 09:29:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22a X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 06:29:40 -0000 14.08.2016 08:03, Michael Zimmermann пишет: > couldn't we generate GUID's based on the current git revision? > this way you reproduce the ISO without even looking at the timestamp. > > I don't know anything about the entropy requirements though. Lets wait for > a reply of the maintainers about that. > EFI GUIDs are compliant with RFC 4122 which means that technically deriving GUID from e.g. http://www.gnu.org/software/grub or even simply timestamp string is absolutely legal as well as basing GUID on "GIT hash namespace". For the purpose of reproducible builds I am not sure what having GUIDs based on GIT revision buys us. It can't distinguish between different instances of generated ISO, it cannot be traced back to GIT hash anyway. So as long as generated GUID has reasonable chance to be different from any other GUID on the system where ISO was booted, it should be good. For GRUB itself it does not matter anyway - it does not use GUID, so FS UUID collision is worse problem. > Thanks > Michael > > On Thu, Aug 11, 2016 at 9:55 PM, Thomas Schmitt wrote: > >> Hi, >> >> i am discussing with Chris Lamb on reproducible-builds@lists. >> alioth.debian.org >> how to make production of bootable ISOs reproducible. The last (yet known) >> obstacle are the pseudo-random GUIDs of the GPT which is produced for EFI >> bootability. >> >> Up to this obstacle it turned out that it will suffice to use the same >> input file tree and the same overall timestamp with xorriso -as mkisofs >> option >> --modification-date=YYYYMMDDhhmmsscc >> which was originally introduced for grub-mkrescue to match in grub.cfg >> search --fs-uuid --set YYYY-MM-DD-hh-mm-ss-cc >> >> I am now wondering whether it would be ok for grub-mkrescue if the GUIDs >> of the GPT would be derived reproducibly from this timestamp by default. >> (Currently they stem from /dev/urandom.) >> >> These GUIDs will of course be unique inside the GPT. But their entropy >> will be low and collisions with other ISOs could happen systematically >> because of nearly identical production times. >> Well, this can happen to the ISO 9660 --fs-uuid string under the same >> circumstances. >> >> >> So my question: >> Is there any reason known why the GPT GUID needs to have better randomness >> than the "search --fs-uuid" string ? >> >> >> Have a nice day :) >> >> Thomas >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >