From mboxrd@z Thu Jan 1 00:00:00 1970 From: doncatnip Subject: Fwd: Re: /dev/urandom Date: Wed, 11 Jul 2018 17:40:40 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8C853476DDD345076CE49B26" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdHET-0005Zm-W9 for guix-devel@gnu.org; Wed, 11 Jul 2018 11:40:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdHES-0007uI-NY for guix-devel@gnu.org; Wed, 11 Jul 2018 11:40:46 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:33180) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdHES-0007u6-Ck for guix-devel@gnu.org; Wed, 11 Jul 2018 11:40:44 -0400 Received: by mail-wr1-x42b.google.com with SMTP id g6-v6so9740333wrp.0 for ; Wed, 11 Jul 2018 08:40:44 -0700 (PDT) Received: from ?IPv6:2003:d2:dbd1:1900:ddc:d9bd:b0fd:7239? (p200300D2DBD119000DDCD9BDB0FD7239.dip0.t-ipconnect.de. [2003:d2:dbd1:1900:ddc:d9bd:b0fd:7239]) by smtp.gmail.com with ESMTPSA id f17-v6sm18169268wrs.46.2018.07.11.08.40.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 08:40:41 -0700 (PDT) In-Reply-To: Content-Language: en-US List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org This is a multi-part message in MIME format. --------------8C853476DDD345076CE49B26 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Of course, I forgot the CC. -------- Forwarded Message -------- Subject: Re: /dev/urandom Date: Wed, 11 Jul 2018 09:58:14 +0100 From: Steffen Schulz To: Leo Famulari I probably got it wrong. but it seems the programs purpose is to build images (boot loaders). I then wonder why it needs to do this during installation. If image building is the programs purpose, it should happen during execution after installation, no ? Users would *most likely* prefer it's actual purpose (proper Images, including optimization) instead of reproducibility. On 10.07.2018 23:40, Leo Famulari wrote: > On Tue, Jul 10, 2018 at 08:58:43PM +0200, Danny Milosavljevic wrote: >> It writes an image file. Since that image is later written to flash storage >> (by the user), the program randomizes the data in order to increase longevity. >> Then it stores the random data used as well. > I see. Like Ludo and Mark, I think we should avoid doing tricky things > with urandom. > > Could /dev/zero work here? Does it use urandom once, to get a seed, or > does it read urandom repeatedly, expecting different values each time? > > Also, I wonder if Guix users would want reproducibility here instead of > longer-lived NAND storage. --------------8C853476DDD345076CE49B26 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Of course, I forgot the CC.

-------- Forwarded Message --------

Subject:	Re: /dev/urandom
Date:	Wed, 11 Jul 2018 09:58:14 +0100
From:	Steffen Schulz <gnopap@gmail.com>
To:	Leo Famulari <leo@famulari.name>

I probably got it wrong.

but it seems the programs purpose is to build images (boot loaders). I 
then wonder why it needs to do this during installation. If image 
building is the programs purpose, it should happen during execution 
after installation, no ?

Users would *most likely* prefer it's actual purpose (proper Images, 
including optimization) instead of reproducibility.

On 10.07.2018 23:40, Leo Famulari wrote:
> On Tue, Jul 10, 2018 at 08:58:43PM +0200, Danny Milosavljevic wrote:
>> It writes an image file.  Since that image is later written to flash storage
>> (by the user), the program randomizes the data in order to increase longevity.
>> Then it stores the random data used as well.
> I see. Like Ludo and Mark, I think we should avoid doing tricky things
> with urandom.
>
> Could /dev/zero work here? Does it use urandom once, to get a seed, or
> does it read urandom repeatedly, expecting different values each time?
>
> Also, I wonder if Guix users would want reproducibility here instead of
> longer-lived NAND storage.

--------------8C853476DDD345076CE49B26-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: doncatnip Subject: Fwd: Re: /dev/urandom Date: Wed, 11 Jul 2018 17:41:05 +0200 Message-ID: <5a86886a-ba39-d42e-b53a-3f329bbfb0b8@gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6C9139A27EA8063B2B796EDA" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdHEs-0005lD-4P for guix-devel@gnu.org; Wed, 11 Jul 2018 11:41:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdHEr-00082j-6Z for guix-devel@gnu.org; Wed, 11 Jul 2018 11:41:10 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:46274) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fdHEq-00082S-V9 for guix-devel@gnu.org; Wed, 11 Jul 2018 11:41:09 -0400 Received: by mail-wr1-x431.google.com with SMTP id s11-v6so18644155wra.13 for ; Wed, 11 Jul 2018 08:41:08 -0700 (PDT) Received: from ?IPv6:2003:d2:dbd1:1900:ddc:d9bd:b0fd:7239? (p200300D2DBD119000DDCD9BDB0FD7239.dip0.t-ipconnect.de. [2003:d2:dbd1:1900:ddc:d9bd:b0fd:7239]) by smtp.gmail.com with ESMTPSA id u4-v6sm3394520wrt.31.2018.07.11.08.41.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 08:41:06 -0700 (PDT) In-Reply-To: Content-Language: en-US List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org This is a multi-part message in MIME format. --------------6C9139A27EA8063B2B796EDA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Of course, I forgot the CC here too. -------- Forwarded Message -------- Subject: Re: /dev/urandom Date: Wed, 11 Jul 2018 17:38:52 +0200 From: doncatnip To: Vincent Legoll I'd guess this is about the distribution of blocks within the image, so that the load of each sector is different from image to image containing the same data. Of course, I'm just speculating as I haven't looked into it - but if that is the case, it would seem even more strange that this random seed is generated during install and not during use of the program. On 7/11/2018 5:07 PM, Vincent Legoll wrote: > On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic > wrote: >> the randomness is necessary for NAND wear levelling, > Any pointers about that subject ? > > This looks strange as I'd have thought that less writes => less wear. > --------------6C9139A27EA8063B2B796EDA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Of course, I forgot the CC here too.

-------- Forwarded Message --------

Subject:	Re: /dev/urandom
Date:	Wed, 11 Jul 2018 17:38:52 +0200
From:	doncatnip <gnopap@gmail.com>
To:	Vincent Legoll <vincent.legoll@gmail.com>

I'd guess this is about the distribution of blocks within the image, so 
that the load of each sector is different from image to image containing 
the same data. Of course, I'm just speculating as I haven't looked into 
it - but if that is the case, it would seem even more strange that this 
random seed is generated during install and not during use of the program.

On 7/11/2018 5:07 PM, Vincent Legoll wrote:
> On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic
> <dannym@scratchpost.org> wrote:
>> the randomness is necessary for NAND wear levelling,
> Any pointers about that subject ?
>
> This looks strange as I'd have thought that less writes => less wear.
>

--------------6C9139A27EA8063B2B796EDA--