Re: [PATCH] Bug 9076 - Whois using a non working host for queries by default

[Rich Felker]

On Mon, Jul 04, 2016 at 09:36:07PM -0500, Rob Landley wrote:
> On 07/04/2016 02:47 PM, Vito Mulè wrote:
> > stopped using strcpy,
> 
> Why?
> 
> > +size_t query_len = strlen(argv_host);
> > +   char *str_token = malloc(query_len+1 * sizeof(char));
> 
> > +   strncpy(str_token, argv_host, query_len+1);
> 
> Ignoring the way you've taken 3 lines to say strdup() (and your
> sizeof(char) is only applying to the 1, not query_len+1, but it's ok
> because sizeof(char) is a constant 1 on every system linux has ever
> supported)...

Not just Linux. sizeof(char) is literally the answer to the question
"how many chars in a char?" or "how big is char in units of char?"

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Bug 9076 - Whois using a non working host for queries by default

[Rob Landley]

On 07/04/2016 02:47 PM, Vito Mulè wrote:
> stopped using strcpy,

Why?

> +size_t query_len = strlen(argv_host);
> +   char *str_token = malloc(query_len+1 * sizeof(char));

> +   strncpy(str_token, argv_host, query_len+1);

Ignoring the way you've taken 3 lines to say strdup() (and your
sizeof(char) is only applying to the 1, not query_len+1, but it's ok
because sizeof(char) is a constant 1 on every system linux has ever
supported)...

My question is that you're effectively doing:

  strncpy(str_token, argv_host, strlen(argv_host)+1);

So how is this better than strcpy()?

> +   strncpy(host, domain, strlen(domain));

Here you're literally doing that. Why?

Rob
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Bug 9076 - Whois using a non working host for queries by default

[Vito Mulè]

fixed typos, stopped using strcpy, added a separate function to create the
name for the whois server and also supporting, as it was before, more than
one query at the time.



Signed-off-by: vmule 


diff --git a/networking/whois.c b/networking/whois.c
index bf33033..908a032 100644
--- a/networking/whois.c
+++ b/networking/whois.c
@@ -44,22 +44,56 @@ static void pipe_out(int fd)
fclose(fp); /* closes fd too */
 }

+void whois_host(char* host, char *argv_host, const char *unqualified_host)
+{
+   char domain[49];
+char* token;
+size_t query_len = strlen(argv_host);
+   char *str_token = malloc(query_len+1 * sizeof(char));
+
+   if (strlen(host) >= 1) {
+   memset([0], 0, strlen(host));
+   }
+
+   strncpy(str_token, argv_host, query_len+1);
+
+   token = strtok(str_token, ".");
+   while (token != NULL) {
+   strncpy(domain, token, strlen(token)+1);
+   token = strtok(NULL, ".");
+   }
+   strncpy(host, domain, strlen(domain));
+   strncat(host, unqualified_host, 19);
+}
+
 int whois_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
 int whois_main(int argc UNUSED_PARAM, char **argv)
 {
+
+   char *host = malloc(67 * sizeof(char));
int port = 43;
-   const char *host = "whois-servers.net";
+   const char *unqualified_host = ".whois-servers.net";

opt_complementary = "-1:p+";
getopt32(argv, "h:p:", , );
-
argv += optind;
-   do {
-   int fd = create_and_connect_stream_or_die(host, port);
-   fdprintf(fd, "%s\r\n", *argv);
-   pipe_out(fd);
+
+if (strlen(host) < 1) {
+   do {
+   whois_host(host, *argv, unqualified_host);
+   int fd = create_and_connect_stream_or_die(host,
port);
+   fdprintf(fd, "%s\r\n", *argv);
+   pipe_out(fd);
+   }
+   while (*++argv);
+   } else {
+   do {
+   int fd = create_and_connect_stream_or_die(host,
port);
+   fdprintf(fd, "%s\r\n", *argv);
+   pipe_out(fd);
+   }
+   while (*++argv);
}
-   while (*++argv);

return EXIT_SUCCESS;
 }

On 4 July 2016 at 17:24, Vito Mulè  wrote:

> Patch attached in the bug:
> https://bugs.busybox.net/show_bug.cgi?id=9076
>
> Signed-off-by: vmule 
>
> diff --git a/networking/whois.c b/networking/whois.c
> index bf33033..5a3dc51 100644
> --- a/networking/whois.c
> +++ b/networking/whois.c
> @@ -48,7 +48,7 @@ int whois_main(int argc, char **argv)
> MAIN_EXTERNALLY_VISIBLE;
>  int whois_main(int argc UNUSED_PARAM, char **argv)
>  {
> int port = 43;
> -   const char *host = "whois-servers.net";
> +   const char *host = "whois.nic.it.";
>
> opt_complementary = "-1:p+";
> getopt32(argv, "h:p:", , );
>
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Bug 9076 - Whois using a non working host for queries by default

[Vito Mulè]

Disregard my previous patch, this should work better.
I added some logic to use $domain.whois-servers.net as server based on the
query's domain.


Signed-off-by: vmule 

diff --git a/networking/whois.c b/networking/whois.c
index bf33033..9a73bbc 100644
--- a/networking/whois.c
+++ b/networking/whois.c
@@ -47,13 +47,32 @@ static void pipe_out(int fd)
 int whois_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
 int whois_main(int argc UNUSED_PARAM, char **argv)
 {
+
+   char *host = malloc(67 * sizeof(char));
+   char domain[49];
+   char* token;
+
int port = 43;
-   const char *host = "whois-servers.net";
+   const char *unqualified_host = ".whois-servers.net";

opt_complementary = "-1:p+";
getopt32(argv, "h:p:", , );
-
argv += optind;
+
+   if (strlen(host) < 1) {
+   size_t query_len = strlen(*argv);
+   char *str_token = malloc(query_len * sizeof(char));
+   strncpy(str_token, *argv, query_len);
+
+   token = strtok(str_token, ".");
+   while (token != NULL) {
+   strcpy(domain, token);
+token = strtok(NULL, ".");
+}
+strncpy(host, domain, strlen(domain));
+strncat(host, unqualified_host, 18);
+   }
+
do {
int fd = create_and_connect_stream_or_die(host, port);
fdprintf(fd, "%s\r\n", *argv);

On 4 July 2016 at 17:24, Vito Mulè  wrote:

> Patch attached in the bug:
> https://bugs.busybox.net/show_bug.cgi?id=9076
>
> Signed-off-by: vmule 
>
> diff --git a/networking/whois.c b/networking/whois.c
> index bf33033..5a3dc51 100644
> --- a/networking/whois.c
> +++ b/networking/whois.c
> @@ -48,7 +48,7 @@ int whois_main(int argc, char **argv)
> MAIN_EXTERNALLY_VISIBLE;
>  int whois_main(int argc UNUSED_PARAM, char **argv)
>  {
> int port = 43;
> -   const char *host = "whois-servers.net";
> +   const char *host = "whois.nic.it.";
>
> opt_complementary = "-1:p+";
> getopt32(argv, "h:p:", , );
>
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Question on bb_info_msg, printf, and bb_error_msg?

[Michael D. Setzer II]

On 4 Jul 2016 at 16:42, Denys Vlasenko wrote:

From:   Denys Vlasenko 
Date sent:  Mon, 4 Jul 2016 16:42:15 +0200
Subject:Re: Question on bb_info_msg, printf, and bb_error_msg?
To: "Michael D. Setzer II" 
Copies to:  busybox 

> On Sun, Jun 26, 2016 at 5:06 AM, Michael D. Setzer II
>  wrote:
> > Posted an earlier message about changes in 1.25.0.
> > At the time, I didn't find mention of these in the changes listed, but 
> > didn't
> > know that it was the change from using bb_info_msg to bb_error_msg that
> > was change output to go to stderr instead of stdout. Noticed that other
> > changes have bb_info_msg going to printf? So, what was the problem with
> > bb_info_msg that it needed to be changed?
> 
> bb_info_msg() had only a handful of users, so it looked inconsistent:
> "if most applets can live without it, maybe all of them could?"
> 
> > And why where some changes
> > to printf and other to bb_error_msg?? Also, noted a major changes in the
> > text, where before they started with a capital letter, but now are all lower
> > case?
> 
> Logging messages almost everywhere were emitted via bb_error_msg.
> Thus, bb_info_msg's which were emitting log messages were converted
> to bb_error_msg. Since bb_error_msg prefixes applet name,
> capitalization was changed.
> 
> bb_info_msg's which emitted other messages were converted to printfs,
> IOW: no change in functionality (still goes to stdout, still not prefixed).

I'll have to check on that? May have been that I saw that output on screen, 
but piping it thru the grep didn't find output. May have been that it is just 
the 
case of the text that was causing the failure in the code. Currently 7 
timezones away for build system, and it is currently offline. Hopefully, will 
have a co-working check on it shortly. Still, changing the case of messages 
will require either adding the -i to grep commands or manually changing text. 
Know that I have seen some out lines have text with same words in different 
case, so have case insensitive seach could cause other issues as well.

Where exactly is the bb_error_msg defined? I though bb_info_msg was for 
output to stdout, and bb_error_msg was for stderr?? 

Thanks.


+--+
  Michael D. Setzer II -  Computer Science Instructor  
  Guam Community College  Computer Center  
  mailto:mi...@kuentos.guam.net
  mailto:msetze...@gmail.com
  Guam - Where America's Day Begins
  G4L Disk Imaging Project maintainer 
  http://sourceforge.net/projects/g4l/
+--+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned:  19,471
Processing time:  32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

BOINC@HOME CREDITS
ABC 16613838.513356   |   EINSTEIN
103574037.45569545684502.862785
ROSETTA 45684502.862785   |   SETI85964346.495298

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[PATCH] Bug 9076 - Whois using a non working host for queries by default

[Vito Mulè]

Patch attached in the bug:
https://bugs.busybox.net/show_bug.cgi?id=9076

Signed-off-by: vmule 

diff --git a/networking/whois.c b/networking/whois.c
index bf33033..5a3dc51 100644
--- a/networking/whois.c
+++ b/networking/whois.c
@@ -48,7 +48,7 @@ int whois_main(int argc, char **argv)
MAIN_EXTERNALLY_VISIBLE;
 int whois_main(int argc UNUSED_PARAM, char **argv)
 {
int port = 43;
-   const char *host = "whois-servers.net";
+   const char *host = "whois.nic.it.";

opt_complementary = "-1:p+";
getopt32(argv, "h:p:", , );
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: whois doesn't work

[Vito Mulè]

the problem is with the server used by the applet:

vmule@agent4:~/busybox$ nslookup whois-servers.net 43
socket.c:1915: internal_send: 0.0.0.43#53: Invalid argument
^C
vmule@agent4:~/busybox$ nslookup whois-servers.net
Server: 192.168.1.254
Address: 192.168.1.254#53

Non-authoritative answer:
Name: whois-servers.net
Address: 204.74.78.75

vmule@agent4:~/busybox$ telnet 204.74.78.75 43
Trying 204.74.78.75...
^C

whois-servers.net

linus whois uses this:

vmule@agent4:~/busybox$ telnet 204.74.78.75 43
Trying 204.74.78.75...
^C
vmule@agent4:~/busybox$ nslookup 192.12.192.242
Server: 192.168.1.254
Address: 192.168.1.254#53

Non-authoritative answer:
242.192.12.192.in-addr.arpa name = whois.nic.it.


using this solves the issue:

vmule@agent4:~/busybox$ ./busybox_unstripped whois www.google.it
Domain: www.google.it
Status: UNASSIGNABLE

Patch incoming.



On 4 July 2016 at 16:52, walter harms  wrote:

>
>
> Am 04.07.2016 17:34, schrieb walter harms:
> >
> >
> > Am 04.07.2016 17:22, schrieb Jody Bruchon:
> >> On 2016-07-04 11:18, Vito Mulè wrote:
> >>> Can you strace it and post the output?
> >>
> >> I can confirm this problem has been going on for a while; one day it
> >> just stopped working. Here's an strace:
> >>
> >>
> >> recvfrom(3, "\254g\201\200\0\1\0\1\0\0\0\0\rwhois-servers\3net\0\0"...,
> >> 1024, 0, {sa_family=AF_INET, sin_port=htons(53),
> >> sin_addr=inet_addr("8.8.8.8")}, [16]) = 51
> >> close(3)= 0
> >> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
> >> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> >> connect(3, {sa_family=AF_INET, sin_port=htons(43),
> >> sin_addr=inet_addr("204.74.78.75")}, 16
> >>
> >
> > just to be sure ..
> > you can ping 204.74.78.75 ?
> >
> >
> > re,
> >  wh
> > ___
>
>
> When i ask for  www.google.com i get 172.217.18.36
> that is something i can ping. Strange, does this google
> configure the servers differently ?
>
> re,
>  wh
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Etienne Champetier]

2016-07-04 17:02 GMT+02:00 Denys Vlasenko :
> On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier
>  wrote:
>>> BTW, I know that security people would scream bloody murder,
>>> but wouldn't
>>>
>>> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
>>> schedstat buddyinfo >/dev/random
>>>
>>> in practice work quite satisfactorily for adding some entropy at boot time?
>>
>> Your cat /proc/* will be almost identical each boot,
>
> Yes, at boot it is somewhat likely, although I'd like someone
> to experiment on a real system.

I will repeat myself, in crypto you prove that it's safe, not the
other way around

>
> But you can also run the same command before key generation.
> I bet at least pids, allocation counts, and allocation addresses
> get randomized pretty fast.

Or I can just use a safe API as it exists ...

>
>> so no it's not
>> adding entropy, or it's re-adding what is already used internaly
>> What we are trying to fight here is having the same state between
>> multiple reboot of the same router, or between multiple identical
>> routers.
>
> I'm sure most of contents of these files are not mixed in to entropy
> pool by the kernel. For one, this data comes from a lot of different places:
> memory allocator, scheduler, disk IO, even hardware CPU frequency scaling.
> Kernel has no code to use all of that, or even half of that, for entropy
> collection.

Maybe kernel maintainers have good reasons to not mix them ...

>
> BTW, add to that /proc/net/*. I mean, literally every file (unlike /proc/*,
> where you don't want to read everything, "kcore" for one may be "a bit" big).
> There are ~50 files in /proc/net/.
> Just one example. /proc/net/unix has Inode column for unix sockets.
> Those depend on the order how processes have started at boot.
> If there is at least some concurrency, inodes will contain some randomness.

Network and radio can add some entropy, everything else is pretty non random.
You are reading the same flash, executing the same code, with the same
1 core cpu, and without a high precision timer.

Crypto 101 is "don't roll your own crypto", the code you are
suggesting will make you feel safe when in reality it will change
almost nothing

Please also reread Bastian Bittorf, in his experience on 100 identical
routers you have at least 2 identical ssh-key !

You haven't answered my question, should i change the applet name to
bbgetrandom ?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: whois doesn't work

[walter harms]

Am 04.07.2016 17:34, schrieb walter harms:
> 
> 
> Am 04.07.2016 17:22, schrieb Jody Bruchon:
>> On 2016-07-04 11:18, Vito Mulè wrote:
>>> Can you strace it and post the output?
>>
>> I can confirm this problem has been going on for a while; one day it
>> just stopped working. Here's an strace:
>>
>>
>> recvfrom(3, "\254g\201\200\0\1\0\1\0\0\0\0\rwhois-servers\3net\0\0"...,
>> 1024, 0, {sa_family=AF_INET, sin_port=htons(53),
>> sin_addr=inet_addr("8.8.8.8")}, [16]) = 51
>> close(3)= 0
>> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
>> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>> connect(3, {sa_family=AF_INET, sin_port=htons(43),
>> sin_addr=inet_addr("204.74.78.75")}, 16
>>
> 
> just to be sure ..
> you can ping 204.74.78.75 ?
> 
> 
> re,
>  wh
> ___


When i ask for  www.google.com i get 172.217.18.36
that is something i can ping. Strange, does this google
configure the servers differently ?

re,
 wh
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: whois doesn't work

[Jody Bruchon]

On 2016-07-04 11:34, walter harms wrote:



Am 04.07.2016 17:22, schrieb Jody Bruchon:

On 2016-07-04 11:18, Vito Mulè wrote:

Can you strace it and post the output?


I can confirm this problem has been going on for a while; one day it
just stopped working. Here's an strace:

$ strace busybox whois www.google.com

---snip---

sin_addr=inet_addr("204.74.78.75")}, 16



just to be sure ..
you can ping 204.74.78.75 ?


No ping, traceroute drops off after 11 hops, and here's the whois:

$ whois -h whois.arin.net 204.74.78.75

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# Query terms are ambiguous.  The query is assumed to be:
# "n 204.74.78.75"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# 
https://whois.arin.net/rest/nets;q=204.74.78.75?showDetails=true=false=false=netref2

#

NetRange:   204.74.64.0 - 204.74.127.255
CIDR:   204.74.64.0/18
NetName:IMN
NetHandle:  NET-204-74-64-0-1
Parent: NET204 (NET-204-0-0-0-0)
NetType:Direct Allocation
OriginAS:
Organization:   Internet Media Network (IMN)
RegDate:1994-10-26
Updated:2000-09-19
Ref:https://whois.arin.net/rest/net/NET-204-74-64-0-1


OrgName:Internet Media Network
OrgId:  IMN
Address:254 W Baseline Rd
Address:#103
City:   Tempe
StateProv:  AZ
PostalCode: 85283
Country:US
RegDate:1994-10-26
Updated:2015-08-18
Ref:https://whois.arin.net/rest/org/IMN
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Denys Vlasenko]

On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier
 wrote:
>> BTW, I know that security people would scream bloody murder,
>> but wouldn't
>>
>> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
>> schedstat buddyinfo >/dev/random
>>
>> in practice work quite satisfactorily for adding some entropy at boot time?
>
> Your cat /proc/* will be almost identical each boot,

Yes, at boot it is somewhat likely, although I'd like someone
to experiment on a real system.

But you can also run the same command before key generation.
I bet at least pids, allocation counts, and allocation addresses
get randomized pretty fast.

> so no it's not
> adding entropy, or it's re-adding what is already used internaly
> What we are trying to fight here is having the same state between
> multiple reboot of the same router, or between multiple identical
> routers.

I'm sure most of contents of these files are not mixed in to entropy
pool by the kernel. For one, this data comes from a lot of different places:
memory allocator, scheduler, disk IO, even hardware CPU frequency scaling.
Kernel has no code to use all of that, or even half of that, for entropy
collection.

BTW, add to that /proc/net/*. I mean, literally every file (unlike /proc/*,
where you don't want to read everything, "kcore" for one may be "a bit" big).
There are ~50 files in /proc/net/.
Just one example. /proc/net/unix has Inode column for unix sockets.
Those depend on the order how processes have started at boot.
If there is at least some concurrency, inodes will contain some randomness.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Question on bb_info_msg, printf, and bb_error_msg?

[Denys Vlasenko]

On Sun, Jun 26, 2016 at 5:06 AM, Michael D. Setzer II
 wrote:
> Posted an earlier message about changes in 1.25.0.
> At the time, I didn't find mention of these in the changes listed, but didn't
> know that it was the change from using bb_info_msg to bb_error_msg that
> was change output to go to stderr instead of stdout. Noticed that other
> changes have bb_info_msg going to printf? So, what was the problem with
> bb_info_msg that it needed to be changed?

bb_info_msg() had only a handful of users, so it looked inconsistent:
"if most applets can live without it, maybe all of them could?"

> And why where some changes
> to printf and other to bb_error_msg?? Also, noted a major changes in the
> text, where before they started with a capital letter, but now are all lower
> case?

Logging messages almost everywhere were emitted via bb_error_msg.
Thus, bb_info_msg's which were emitting log messages were converted
to bb_error_msg. Since bb_error_msg prefixes applet name,
capitalization was changed.

bb_info_msg's which emitted other messages were converted to printfs,
IOW: no change in functionality (still goes to stdout, still not prefixed).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Etienne Champetier]

2016-07-03 18:46 GMT+02:00 Denys Vlasenko :
> On Tue, Jun 28, 2016 at 7:47 PM, walter harms  wrote:
>> perhaps a better aim ist to improve the $RANDOM in ash ?
>
>
> $RAMDOM generator in my tests passed all "dieharder -g 200 -a" tests.
> How much better than this do you need?

The problem is between reboot of the same device or between multiple
identical devices, you will have the same state.
Take AES in CTR mode with key 0 and counter 0, it will pass dieharder
with no problem, but the next boot will be predictible.

CSPRNG depend on having a good seed, ie having finished the
initialization, and you know that init is done when getrandom()
unblocks.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Etienne Champetier]

Hi Denys

TLDR: /dev/urandom is safe once initialized,
initialization take a long time on embedded device
=> use getrandom() to wait for initialization and be safe

2016-07-03 18:44 GMT+02:00 Denys Vlasenko :
> On Tue, Jun 28, 2016 at 6:56 PM, Etienne CHAMPETIER
>  wrote:
>> first user of this applet will be LEDE (OpenWrt) to save an urandom seed
>> using getrandom() (so we are sure /dev/urandom pool is initialized)
>
>
> Please be more specific which task you want to achieve with this tool.

I want to read from /dev/urandom but only when it's initialized, and
the way to do that is the getrandom() syscall.
If you use /dev/urandom too early you might have the same state
between reboots of a router, or between multiple identical routers.

A non busybox version of getrandom is already in LEDE (OpenWrt), i
just want to integrate it into busybox to take less space
https://git.lede-project.org/?p=project/ubox.git;a=commit;h=fdda69207d1509e0383e3da549f71666b194c40a
https://git.lede-project.org/?p=source.git;a=commit;h=9ba0dc602f7fb52c4e792922c20e8e7390d1a10c
https://git.lede-project.org/?p=source.git;a=commit;h=3946a5529132c80793a9e5ee665a3cd6b0835310

>
> I googled for this name and no such tool exists (yet?) in distros,
> I hesitate to introduce a new tool and then have an API collision
> when they add something similar.

On desktop /dev/random is initialized quite early so it's not a
problem, and in the VM world you have special drivers (virtio-rng,
vmware tools, ...) or software (pollinate, haveged, ...)
so using /dev/urandom isn't a problem

But in the embedded world (think crappy router) you don't have that
much entropy (on some of my routers it take 1 min for /dev/urandom to
be initialized) and you don't have space or power (device on battery)
to have special software, so if you want to be sure that /dev/urandom
is initialized (has been seeded with 128bits of entropy), you use
getrandom()

I can change the name of the applet to "bbgetrandom" to avoid API
collision in the future?

>
> BTW, I know that security people would scream bloody murder,
> but wouldn't
>
> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
> schedstat buddyinfo >/dev/random
>
> in practice work quite satisfactorily for adding some entropy at boot time?

Your cat /proc/* will be almost identical each boot, so no it's not
adding entropy, or it's re-adding what is already used internaly
What we are trying to fight here is having the same state between
multiple reboot of the same router, or between multiple identical
routers.

> If you don't think so, can you demonstrate a setup where the output is
> predictable?

In the crypto world you prove that things are safe, and not having a
proof that it's broken doesn't mean that it's safe, it's just that you
haven't try hard enough ;)
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] getrandom: new applet

[Bastian Bittorf]

* Denys Vlasenko  [04.07.2016 09:06]:
> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo
> schedstat buddyinfo >/dev/random
> 
> in practice work quite satisfactorily for adding some entropy at boot time?
> If you don't think so, can you demonstrate a setup where the output is
> predictable?

setup 100 identical embedded boards with the same image end
you will end up with having at least 2 with the same private key.

we are doing this in our setup and after setup we compare all ssh-keys.
entropy is a bitch.

bye, bastian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox