Mailing List Archive

Re: Bug#412408: Is invoking exit(2) in a library the right thing to do?
On Thu, 15 Nov 2007 10:55, trs80@ucc.gu.uwa.edu.au said:

> The only way forward I can see from here is to refer the issue to the
> Technical Committee. If nobody objects or wants to do it themselves
> I'll write up a summary when I have some free time.

I still do not understand the problem. Do you say that in an early boot
phase /dev/random is not yet mknod-ed or mounted? If that is the case,
how at all does the boot process work without /dev/null - that it is
universally used before exec. I don't understand where the difference
is.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Thu, 15 Nov 2007, Werner Koch wrote:

> On Thu, 15 Nov 2007 10:55, trs80@ucc.gu.uwa.edu.au said:
>
>> The only way forward I can see from here is to refer the issue to the
>> Technical Committee. If nobody objects or wants to do it themselves
>> I'll write up a summary when I have some free time.
>
> I still do not understand the problem. Do you say that in an early boot
> phase /dev/random is not yet mknod-ed or mounted? If that is the case,
> how at all does the boot process work without /dev/null - that it is
> universally used before exec. I don't understand where the difference
> is.

There is a file in the udev package, /etc/udev/links.conf, which is parsed
by make_extra_nodes() in /etc/init.d/udev to create a minimal /dev for
udev to bootstrap itself on. /etc/udev/links.conf contains a line:
M null c 1 3
which creates /dev/null, but does not contain a line to create
/dev/random. It also contains the comment:
# This file does not exist. Please do not ask the debian maintainer about it.


--
# TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best |
[ "There's nobody getting rich writing ]| -- Collect and hide your |
[ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 /


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Thu, 15 Nov 2007 13:19, trs80@ucc.gu.uwa.edu.au said:

> M null c 1 3
> which creates /dev/null, but does not contain a line to create
> /dev/random. It also contains the comment:

So the fix should be pretty easy:

M random c 1 8
M urandom c 1 9


Shalom-Salam,

Werner


p.s.
Does the volume level wheel of that old box's tape deck still work? ;-)

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Nov 15, Werner Koch <wk@gnupg.org> wrote:

> So the fix should be pretty easy:
>
> M random c 1 8
> M urandom c 1 9
I oppose this "solution", the only devices which *must* be created
statically (and are available in the standard initramfs indeed) are null
and console.

SSL is not used at this time of the boot process: there is no
networking, so the query is expected to (gracefully) fail anyway.

--
ciao,
Marco
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Thu, 15 Nov 2007, Marco d'Itri wrote:

> On Nov 15, Werner Koch <wk@gnupg.org> wrote:
>
>> So the fix should be pretty easy:
>>
>> M random c 1 8
>> M urandom c 1 9
> I oppose this "solution", the only devices which *must* be created
> statically (and are available in the standard initramfs indeed) are null
> and console.
>
> SSL is not used at this time of the boot process: there is no
> networking, so the query is expected to (gracefully) fail anyway.

There is networking - the machines netboot.

--
# TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best |
[ "There's nobody getting rich writing ]| -- Collect and hide your |
[ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 /


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Thu, 15 Nov 2007 15:32, md@Linux.IT said:

> I oppose this "solution", the only devices which *must* be created
> statically (and are available in the standard initramfs indeed) are null
> and console.

With this reasoning you may also change Linux to allow /dev/random to be
a module. It was conscious decisions, more than a decade ago, to have
/dev/random *always* available. Thus it is as important as /dev/null
and more usefule than console.

> SSL is not used at this time of the boot process: there is no
> networking, so the query is expected to (gracefully) fail anyway.

It is not only used for networking but also for login services and all
kind of other non-networking stuff.

But if you really don't like to have /dev/random, you may configure
libgcrypt with --enable-random=auto and it will fall back to rndunix
which has the little disadvantage of running dozens of system utilities
to build up the entropy pool. I wonder whether this has really any
advantage over creating a node for an already existing device.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
* Werner Koch:

> On Thu, 15 Nov 2007 13:19, trs80@ucc.gu.uwa.edu.au said:
>
>> M null c 1 3
>> which creates /dev/null, but does not contain a line to create
>> /dev/random. It also contains the comment:
>
> So the fix should be pretty easy:
>
> M random c 1 8
> M urandom c 1 9

Indeed. And you should call abort() instead of exit() in the library.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Sun, 18 Nov 2007 12:10, fw@deneb.enyo.de said:

> Indeed. And you should call abort() instead of exit() in the library.

I will consider this.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Nov 15, Werner Koch <wk@gnupg.org> wrote:

> With this reasoning you may also change Linux to allow /dev/random to be
> a module. It was conscious decisions, more than a decade ago, to have
> /dev/random *always* available. Thus it is as important as /dev/null
> and more usefule than console.
If this were true then it would be available in the kernel default
initramfs (scripts/gen_initramfs_list.sh).

--
ciao,
Marco
Re: Bug#412408: Is invoking exit(2) in a library the right thing to do? [ In reply to ]
On Sun, 13 Apr 2008 04:05, md@Linux.IT said:
> On Nov 15, Werner Koch <wk@gnupg.org> wrote:
>
>> With this reasoning you may also change Linux to allow /dev/random to be
>> a module. It was conscious decisions, more than a decade ago, to have
>> /dev/random *always* available. Thus it is as important as /dev/null
>> and more usefule than console.
> If this were true then it would be available in the kernel default
> initramfs (scripts/gen_initramfs_list.sh).

I don't know enough about this to tell why it does not mknod
/dev/random. Given that TCP requires the random device and thus the
devices needs to be available, it might just be the case that until now
the userland had no need for the device node.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel