Menu
▾
▴
unbound-core — core developers on unbound
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(28) |
Mar
(1) |
Apr
(20) |
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(37) |
Dec
|
|---|
|
From: Lurene A. G. <lu...@da...> - 2002-11-28 22:28:24
|
It's just not nearly done AT ALL. ;) I just imported what I had,
basically the token and types list and some minor grammer stuff.
Lurene
--
"What I cannot create, I cannot understand"
-- Richard Feynman
|
|
From: Jose N. <jo...@mo...> - 2002-11-27 04:16:25
|
On Tue, 26 Nov 2002, Juli Mallett wrote: > That's meaningless, unless we're using a pfctl grammar or something. no, it means its not an artifact of just saying "yacc file.y". > It seems to me like the grammar is just somewhat incomplete. *nods* ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Juli M. <jma...@Fr...> - 2002-11-27 02:54:29
|
* De: Jose Nazario <jo...@mo...> [ Data: 2002-11-26 ] [ Subjecte: [Unbound-core] src/named/parse.y ] > hi lurene > > this is what i get when i try and compile parse.y: > > $ yacc parse.y > parse.y: the symbol address_match_list is undefined > parse.y: the symbol domain_name is undefined > parse.y: the symbol dotted_decimal is undefined > parse.y: the symbol ip4_addr is undefined > parse.y: the symbol stmt is undefined > parse.y: the symbol ip6_addr is undefined > parse.y: the symbol ip_addr is undefined > parse.y: the symbol ip_port is undefined > parse.y: the symbol ip_prefix is undefined > parse.y: the symbol key_id is undefined > parse.y: the symbol key_list is undefined > parse.y: the symbol number is undefined > parse.y: the symbol path_name is undefined > parse.y: the symbol size_spec is undefined > parse.y: the symbol yes_or_no is undefined > parse.y: the symbol dialup_option is undefined > > > for comparison's sake yacc parse.y in pfctl's src tree doesn't give > errors. That's meaningless, unless we're using a pfctl grammar or something. > looks like some things in the header are missing. It seems to me like the grammar is just somewhat incomplete. -- Juli Mallett <jma...@Fr...> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. |
|
From: Jose N. <jo...@mo...> - 2002-11-27 01:58:46
|
hi lurene this is what i get when i try and compile parse.y: $ yacc parse.y parse.y: the symbol address_match_list is undefined parse.y: the symbol domain_name is undefined parse.y: the symbol dotted_decimal is undefined parse.y: the symbol ip4_addr is undefined parse.y: the symbol stmt is undefined parse.y: the symbol ip6_addr is undefined parse.y: the symbol ip_addr is undefined parse.y: the symbol ip_port is undefined parse.y: the symbol ip_prefix is undefined parse.y: the symbol key_id is undefined parse.y: the symbol key_list is undefined parse.y: the symbol number is undefined parse.y: the symbol path_name is undefined parse.y: the symbol size_spec is undefined parse.y: the symbol yes_or_no is undefined parse.y: the symbol dialup_option is undefined for comparison's sake yacc parse.y in pfctl's src tree doesn't give errors. looks like some things in the header are missing. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Jose N. <jo...@mo...> - 2002-11-26 00:54:16
|
i started making use of the docs section in unbound. we now have a design doc (prelim) and an early requirements doc. they are also in cvs. please review and let me know what you think should be added, should go, and what needs to be reworded. thanks, ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Juli M. <jma...@Fr...> - 2002-11-19 21:25:58
|
* De: Jose Nazario <jo...@mo...> [ Data: 2002-11-19 ] [ Subjecte: Re: [Unbound-core] proposed diff: vcli_loop() ] > attempt 3 of ... how many? anyhow .. > > o no more prompt truncation, juli convinced me > o def the prompt callback as a const char * > > unit tested on openbsd-2.8 i386. Looks cool to me and I don't see anything that'd be problematic on either of the platforms I'm interested in. -- Juli Mallett <jma...@Fr...> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. |
|
From: Jose N. <jo...@mo...> - 2002-11-19 20:26:00
|
attempt 3 of ... how many? anyhow .. o no more prompt truncation, juli convinced me o def the prompt callback as a const char * unit tested on openbsd-2.8 i386. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Juli M. <jma...@Fr...> - 2002-11-19 19:57:22
|
* De: Jose Nazario <jo...@mo...> [ Data: 2002-11-19 ] [ Subjecte: Re: [Unbound-core] proposed diff: vcli_loop() ] > new diff attached, with juli's suggestions this compiles cleanly and unit > tests correctly. > > a couple of followups: > > > I don't understand why we strlcpy? Also, strlcpy was used wrong, I > > think, so I added an XXX. > > trucation occurs to enforce a usable size of prompt. If a CLI app wants to do a long long long prompt, I don't see why we should enforce otherwise. It should enforce usable length, as long it knows how to truncate properly... Which we don't. We may truncate away useful information and at least will truncate away something like the '>' or whatever representing where input goes. The one I added an XXX for is bogus (i.e. misused) anyway. > comments in between sections in cli.3 to visually break it up. makes > editing easier. > > this code will need some commenting soon ... > > please comment on the diff and give further suggestions as needed. > > ___________________________ > jose nazario, ph.d. jo...@mo... > http://www.monkey.org/~jose/ > ? test/test2.c > Index: cli.c > =================================================================== > RCS file: /cvsroot/unbound/unbound/lib/cli/cli.c,v > retrieving revision 1.5 > diff -u -r1.5 cli.c > --- cli.c 19 Nov 2002 05:30:54 -0000 1.5 > +++ cli.c 19 Nov 2002 19:42:20 -0000 > @@ -68,7 +68,7 @@ > char *input, *forward[MAX_TOKENS]; > > if (streamout != NULL) > - fprintf(streamout, "%s", prompt); /* XXX */ > + fprintf(streamout, "%s", cli_prompt); /* XXX */ > > if ((input = fparseln(streamin, NULL, NULL, NULL, 0)) == NULL) { > break; > @@ -89,4 +89,54 @@ > fclose(streamout); > fclose(streamin); > return (0); > +} > + > +int > +vcli_loop(int fdin, int fdout, prompt_handler p_callback, cli_handler callback) { > + char *p; > + FILE *streamin; > + FILE *streamout = NULL; > + size_t len; > + > + if ((streamin = fdopen(fdin, "r")) == NULL) { > + warn("Failed to open specified file descriptor"); > + return(errno); > + } > + > + if (fdout > -1) > + if ((streamout = fdopen(fdout, "w+")) == NULL) { > + warn("Failed to open specific file descriptor"); > + return(errno); > + } > + > + for (;;) { > + int i = 0; > + char *input, *forward[MAX_TOKENS]; > + char cli_prompt[MAX_PROMPT_SIZE]; > + > + if (streamout != NULL) { > + strlcpy((char *)cli_prompt, (const char *)p_callback(), Don't need the first cast, and the prompt things should prolly return const, actually. > + MAX_PROMPT_SIZE); > + fprintf(streamout, "%s", cli_prompt); > + } > + > + if ((input = fparseln(streamin, NULL, NULL, NULL, 0)) == NULL) { > + break; > + } > + > + for (; i < MAX_TOKENS-1 && > + (forward[i] = strsep(&input, " \t")) != NULL;) > + if (*forward[i] != '\0') > + i++; > + > + if (i > 0) > + if (callback (i, forward) < 0) > + return (-1); > + free(input); > + } > + > + if (streamout != NULL) > + fclose(streamout); > + fclose(streamin); > + return(0); > } > Index: include/cli.h > =================================================================== > RCS file: /cvsroot/unbound/unbound/lib/cli/include/cli.h,v > retrieving revision 1.3 > diff -u -r1.3 cli.h > --- include/cli.h 19 Nov 2002 04:43:39 -0000 1.3 > +++ include/cli.h 19 Nov 2002 19:42:20 -0000 > @@ -30,6 +30,8 @@ > > typedef int (*cli_handler)(int, char *[]); > int cli_loop(int, int, const char *, cli_handler); > +typedef *(*prompt_handler)(); typedef const char *(*prompt_handler)(void) actually, or typedef char *(*prompt_handler)(void) if we don't need it to be const (though we probably want it to). > +int vcli_loop(int, int, prompt_handler, cli_handler); > > #define MAX_PROMPT_SIZE 255 > #define MAX_TOKENS 512 > Index: man/cli.3 > =================================================================== > RCS file: /cvsroot/unbound/unbound/lib/cli/man/cli.3,v > retrieving revision 1.4 > diff -u -r1.4 cli.3 > --- man/cli.3 19 Nov 2002 04:43:39 -0000 1.4 > +++ man/cli.3 19 Nov 2002 19:42:20 -0000 > @@ -13,6 +13,9 @@ > .Fd #include <cli.h> > .Ft int > .Fn cli_loop "int fdin" "int fdout" "const char *prompt" "cli_handler callback" > +.Ft int > +.Fn vcli_loop "int fdin" "int fdout" "prompt_handler p_callback" "cli_handler callback" > +.\" > .Sh DESCRIPTION > .Nm > provides a simple API to develop command line based utilities. > @@ -36,13 +39,28 @@ > as an error. Setting > .Fa fdout > to -1 causes the output from cli_loop to be silenced. This is designed for > -non interactive shells. > +non interactive shells. The maximum size of > +.Fa prompt > +is > +.Fa MAX_PROMPT_SIZE > +with truncation ocurring for longer prompts. > +.Pp > +.Fn vcli_loop > +is like > +.Fn cli_loop > +only the displayed prompt is evaluated by > +.Fa p_callback > +each time to determine its format. This is useful for systems where the > +prompt changes in response to some environmental factor, such as priviledge > +level or mode. > +.\" > .Sh BUGS > To link completely against > .Nm > you will also have to link against the > .Fa libutil > library. No other bugs known, aside from the fact that this is a dumb library. > +.\" > .Sh AUTHORS > Jose Nazario > .Aq jo...@mo... Thanks, juli. -- Juli Mallett <jma...@Fr...> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. |
|
From: Jose N. <jo...@mo...> - 2002-11-19 19:45:30
|
new diff attached, with juli's suggestions this compiles cleanly and unit tests correctly. a couple of followups: > I don't understand why we strlcpy? Also, strlcpy was used wrong, I > think, so I added an XXX. trucation occurs to enforce a usable size of prompt. comments in between sections in cli.3 to visually break it up. makes editing easier. this code will need some commenting soon ... please comment on the diff and give further suggestions as needed. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Juli M. <jma...@Fr...> - 2002-11-19 18:19:51
|
* De: Jose Nazario <jo...@mo...> [ Data: 2002-11-19 ]
[ Subjecte: [Unbound-core] proposed diff: vcli_loop() ]
> this patch adds the library function vcli_loop(), which uses a variable
> prompt. it is documented in the cli.3 manpage if you would like to see. i
> haven't been able to get it to work, mainly because of a problem revealed
> by the compiler:
>
> cli.c:119: warning: passing arg 2 of `strlcpy' makes pointer from integer
> without a cast
>
> have a look, please fix up, but more importantly is the interface decent
> and clean?
>
> this patch also fixes a minor misuse of prompt vs cli_prompt in
> cli_loop():
>
> - fprintf(streamout, "%s", prompt); /* XXX */
> + fprintf(streamout, "%s", cli_prompt); /* XXX */
>
> basically we truncated (via strlcpy()) for nothing, this uses what we
> intended to use.
I don't understand why we strlcpy? Also, strlcpy was used wrong, I think,
so I added an XXX.
> ? test/test2.c
> Index: cli.c
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/cli.c,v
> retrieving revision 1.5
> diff -u -r1.5 cli.c
> --- cli.c 19 Nov 2002 05:30:54 -0000 1.5
> +++ cli.c 19 Nov 2002 18:08:03 -0000
> @@ -68,7 +68,7 @@
> char *input, *forward[MAX_TOKENS];
>
> if (streamout != NULL)
> - fprintf(streamout, "%s", prompt); /* XXX */
> + fprintf(streamout, "%s", cli_prompt); /* XXX */
>
> if ((input = fparseln(streamin, NULL, NULL, NULL, 0)) == NULL) {
> break;
> @@ -89,4 +89,54 @@
> fclose(streamout);
> fclose(streamin);
> return (0);
> +}
> +
> +int
> +vcli_loop(int fdin, int fdout, prompt_handler p_callback, cli_handler callback) {
> + char *p;
> + FILE *streamin;
> + FILE *streamout = NULL;
> + size_t len;
> +
> + if ((streamin = fdopen(fdin, "r")) == NULL) {
> + warn("Failed to open specified file descriptor");
> + return(errno);
> + }
> +
> + if (fdout > -1)
> + if ((streamout = fdopen(fdout, "w+")) == NULL) {
> + warn("Failed to open specific file descriptor");
> + return(errno);
> + }
> +
> + for (;;) {
> + int i = 0;
> + char *input, *forward[MAX_TOKENS];
> + char *cli_prompt[MAX_PROMPT_SIZE];
No. You don't want an array of pointers to characters for cli_prompt, you
want an array of characters.
> + if (streamout != NULL) {
> + strlcpy((char *)cli_prompt, p_callback(),
> + MAX_PROMPT_SIZE);
> + fprintf(streamout, "%s", cli_prompt);
> + }
> +
> + if ((input = fparseln(streamin, NULL, NULL, NULL, 0)) == NULL) {
> + break;
> + }
> +
> + for (; i < MAX_TOKENS-1 &&
> + (forward[i] = strsep(&input, " \t")) != NULL;)
> + if (*forward[i] != '\0')
> + i++;
> +
> + if (i > 0)
> + if (callback (i, forward) < 0)
> + return (-1);
> + free(input);
> + }
> +
> + if (streamout != NULL)
> + fclose(streamout);
> + fclose(streamin);
> + return(0);
> }
> Index: include/cli.h
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/include/cli.h,v
> retrieving revision 1.3
> diff -u -r1.3 cli.h
> --- include/cli.h 19 Nov 2002 04:43:39 -0000 1.3
> +++ include/cli.h 19 Nov 2002 18:08:03 -0000
> @@ -30,6 +30,8 @@
>
> typedef int (*cli_handler)(int, char *[]);
> int cli_loop(int, int, const char *, cli_handler);
> +typedef char (*prompt_handler)();
No.
typedef char *(*prompt_handler)(void);
It might make sense to use _t for all these opaque types, otherwise it's
confusing, and prevents the use of obvious things like:
prompt_handler_t prompt_handler
> +int vcli_loop(int, int, prompt_handler, cli_handler);
>
> #define MAX_PROMPT_SIZE 255
> #define MAX_TOKENS 512
> Index: man/cli.3
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/man/cli.3,v
> retrieving revision 1.4
> diff -u -r1.4 cli.3
> --- man/cli.3 19 Nov 2002 04:43:39 -0000 1.4
> +++ man/cli.3 19 Nov 2002 18:08:03 -0000
> @@ -13,6 +13,9 @@
> .Fd #include <cli.h>
> .Ft int
> .Fn cli_loop "int fdin" "int fdout" "const char *prompt" "cli_handler callback"
> +.Ft int
> +.Fn vcli_loop "int fdin" "int fdout" "prompt_handler p_callback" "cli_handler callback"
> +.\"
Below.
> .Sh DESCRIPTION
> .Nm
> provides a simple API to develop command line based utilities.
> @@ -37,12 +40,23 @@
> .Fa fdout
> to -1 causes the output from cli_loop to be silenced. This is designed for
> non interactive shells.
> +.Pp
> +.Fn vcli_loop
> +is like
> +.Fn cli_loop
> +only the displayed prompt is evaluated by
> +.Fa p_callback
> +each time to determine its format. This is useful for systems where the
> +prompt changes in response to some environmental factor, such as priviledge
> +level or mode.
> +.\"
Below.
> .Sh BUGS
> To link completely against
> .Nm
> you will also have to link against the
> .Fa libutil
> library. No other bugs known, aside from the fact that this is a dumb library.
> +.\"
Why the comments before each section?
> .Sh AUTHORS
> Jose Nazario
> .Aq jo...@mo...
Thanks!
juli.
--
Juli Mallett <jma...@Fr...>
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
|
|
From: Jose N. <jo...@mo...> - 2002-11-19 18:10:52
|
this patch adds the library function vcli_loop(), which uses a variable prompt. it is documented in the cli.3 manpage if you would like to see. i haven't been able to get it to work, mainly because of a problem revealed by the compiler: cli.c:119: warning: passing arg 2 of `strlcpy' makes pointer from integer without a cast have a look, please fix up, but more importantly is the interface decent and clean? this patch also fixes a minor misuse of prompt vs cli_prompt in cli_loop(): - fprintf(streamout, "%s", prompt); /* XXX */ + fprintf(streamout, "%s", cli_prompt); /* XXX */ basically we truncated (via strlcpy()) for nothing, this uses what we intended to use. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Juli M. <jma...@Fr...> - 2002-11-19 03:08:34
|
> Index: cli.c
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/cli.c,v
> retrieving revision 1.3
> diff -u -r1.3 cli.c
> --- cli.c 19 Nov 2002 01:19:36 -0000 1.3
> +++ cli.c 19 Nov 2002 02:52:42 -0000
> @@ -43,25 +43,34 @@
> #include "cli.h"
>
> int
> -cli_loop(int fd, const char *prompt, cli_handler callback) {
> +cli_loop(int fdin, int fdout, const char *prompt, cli_handler callback) {
> char *cli_prompt[MAX_PROMPT_SIZE];
> char *p;
> - FILE *stream;
> + FILE *streamin, *streamout;
> size_t len;
>
> strlcpy((char *)cli_prompt, prompt, MAX_PROMPT_SIZE); /* XXX */
>
> - if ((stream = fdopen (fd, "r")) == NULL) {
> + if ((streamin = fdopen (fdin, "r")) == NULL) {
> warn("Failed to open specified file descriptor");
> return(errno);
> }
>
> + if (fdout > -1) {
> + if ((streamout = fdopen (fdout, "w+")) == NULL) {
> + warn("Failed to open specified file descriptor");
> + return(errno);
> + }
> + } else {
> + streamout = fopen("/dev/null", "w+");
> + }
I'd take a different approach here, by setting 'streamout = NULL' at the
beginning of the function, and avoiding this 'else' altogether, and then...
> +
> for (;;) {
> int i = 0;
> char *input, *forward[MAX_TOKENS], **temp;
>
> - fprintf(stdout, "%s", prompt); /* XXX */
> - if ((input = fparseln(stream, NULL, NULL, NULL, 0)) == NULL) {
> + fprintf(streamout, "%s", prompt); /* XXX */
Here I would do:
if (streamout != NULL)
fprintf(streamout, "%s", prompt);
In accordance with the above.
> + if ((input = fparseln(streamin, NULL, NULL, NULL, 0)) == NULL) {
> break;
> }
>
> @@ -78,6 +87,7 @@
> free(input);
> }
>
> - fclose(stream);
> + fclose(streamout);
I don't recall if fclose(NULL) has any special meaning, so I'd add a
check for NULL as above, too.
> + fclose(streamin);
> return (0);
> }
> Index: include/cli.h
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/include/cli.h,v
> retrieving revision 1.2
> diff -u -r1.2 cli.h
> --- include/cli.h 19 Nov 2002 01:16:19 -0000 1.2
> +++ include/cli.h 19 Nov 2002 02:52:42 -0000
> @@ -29,7 +29,7 @@
> #define CLI_H
>
> typedef int (*cli_handler)(int, char *[]);
> -int cli_loop(int, const char *, cli_handler);
> +int cli_loop(int, int, const char *, cli_handler);
>
> #define MAX_PROMPT_SIZE 255
> #define MAX_TOKENS 512
> Index: man/cli.3
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/man/cli.3,v
> retrieving revision 1.3
> diff -u -r1.3 cli.3
> --- man/cli.3 19 Nov 2002 02:14:28 -0000 1.3
> +++ man/cli.3 19 Nov 2002 02:52:42 -0000
> @@ -12,17 +12,19 @@
> .Sh SYNOPSIS
> .Fd #include <cli.h>
> .Ft int
> -.Fn cli_loop "int fd" "const char *prompt" "cli_handler callback"
> +.Fn cli_loop "int fdin" "int fdout" "const char *prompt" "cli_handler callback"
> .Sh DESCRIPTION
> .Nm
> provides a simple API to develop command line based utilities.
> .Pp
> .Fn cli_loop
> enters an infinite loop listening on
> -.Fa fd
> +.Fa fdin
> for input, presenting
> .Fa prompt
> -each time, and using
> +each time on
> +.Fa fdout
> +and using
> .Fa callback
> to process the input.
> .Fa callback
> @@ -31,7 +33,10 @@
> number of arguments and a char
> .Fa args
> which is read from the command line. Any non-zero return value is treated
> -as an error.
> +as an error. Setting
> +.Fa fdout
> +to -1 causes the output from cli_loop to be silenced. This is designed for
> +non interactive shells.
> .Sh BUGS
> To link completely against
> .Nm
> Index: test/test1.c
> ===================================================================
> RCS file: /cvsroot/unbound/unbound/lib/cli/test/test1.c,v
> retrieving revision 1.2
> diff -u -r1.2 test1.c
> --- test/test1.c 19 Nov 2002 01:16:19 -0000 1.2
> +++ test/test1.c 19 Nov 2002 02:52:42 -0000
> @@ -9,7 +9,7 @@
> {
> printf("c %d, v %s\n", argc, *argv);
>
> - cli_loop(1, "test1> ", print_opts);
> + cli_loop(0, 1, "test1> ", print_opts);
STDIN_FILENO and STDOUT_FILENO may be a good idea.
>
> exit(0);
> }
Other than that it's OK with me :)
Thanks,
juli.
--
Juli Mallett <jma...@Fr...>
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.
|
|
From: Jose N. <jo...@mo...> - 2002-11-19 02:53:05
|
this one compiles. a spurious ) got in the way on line 65. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Jose N. <jo...@mo...> - 2002-11-19 02:51:45
|
the attached diff changes the api in cli_loop to accepting two file descriptors now, fd in (to read from) and fd out (to pass the prompt to). tested on openbsd-current using test1. the goal is to allow for the silent operation of a cli_loop() paarsing a file, for example, by setting fd out to -1 (it just sets streamout to /dev/null, w+). feedback welcome. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Juli M. <jma...@Fr...> - 2002-11-15 07:13:41
|
* De: Lurene Angela Grenier <lu...@da...> [ Data: 2002-11-14 ] [ Subjecte: [Unbound-core] unbound dig ] > Since we want to make a drop in replacement for bind, do we need to > have all command line arguments to bind dig be the same? I wouldn't mind > except that this is not posix, and consequently not supported by getopt(). > > Is it more important to be the same as bind9, or posix compliant? > (using getopt() significantly lowers thre chances of a bad parser having a hole) Parsing command line arguments is significantly more trivial than the average things which would lead to a "hole" in a parser. If the command is called "dig" it should do its best to act like dig, IMO. Even if it's passed to an unbound client program which has getopt(3) style arguments, and just parsed for the dig style first. I'm a bit unclear about what sorts of holes you're even alluding to, anyway, because of the nature of user-driven programs which are not setuid/setgid/... Even if dig were setuid/setgid, it would be possible to do the parsing in an unprivleged manner, if it were so poorly programmed as to require such an environment, and such that it could not simply be made to parse properly. juli. -- Juli Mallett <jma...@Fr...> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. |
|
From: Lurene A. G. <lu...@da...> - 2002-11-15 06:51:49
|
Since we want to make a drop in replacement for bind, do we need to
have all command line arguments to bind dig be the same? I wouldn't mind
except that this is not posix, and consequently not supported by getopt().
Is it more important to be the same as bind9, or posix compliant?
(using getopt() significantly lowers thre chances of a bad parser having a hole)
Lurene
--
"What I cannot create, I cannot understand"
-- Richard Feynman
|
|
From: Jose N. <jo...@mo...> - 2002-11-13 23:41:52
|
$ ls -l total 2 drwxr-xr-x 2 jose jose 512 Nov 13 18:44 CVS $ pwd /var/src/unbound unbound is clean. cvs rm'd everything. feel free to check in stuff. i am creating a small set of files and directories for us: README DESIGN/ ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Rick W. <rw...@ci...> - 2002-11-12 17:30:15
|
On Tue, Nov 12, 2002 at 12:17:58PM -0500, Jose Nazario wrote: > On Tue, 12 Nov 2002, Rick Wash wrote: > > > char volitile *key; > > actually the standard says this can be ignored, IIRC. hence, it can be > optimized away. gcc 3.2 does, for example. Actually, no it doesn't. Perry Metzger posted an excerpt from the C99 spec that states that it is NOT optional and must be honored. Also, any compiler that optimizes it away during kernel builds will break a large number of device drivers as they frequently rely on this to get correct behavior from the compiler. Third, there is no better solution out there. All of the other proposed workarounds are completely non-standard and may or may not work in any given compiler, present or future. I say if people are dumb enough to compile this with a broken compiler, then they are taking the risk. Note, many people do not properly understand the volitile keyword and think that "volitile char *" means that the memory is volitile. It doesn't. It means that the pointer is volitile but the memory accesses can be treated normally. "char volitile *" means the memory is volitile and all accesses to it must be honored. "volitile char volitile *" means both memory and pointer are volitile. This causes much confusion on the lists as people were compiling "volitile char *" and complaining when gcc optimized it away. (And yes, I read most of all of those threads) > as for libevent: we use it at work to avoid being multithreaded and use it > to handle a shit ton of data. scaling problems are typically not a > problem. Cool. Didn't realize libevent scaled that well. If it truely does scale that well, maybe we won't need multithreaded stuff! Rick |
|
From: Jose N. <jo...@mo...> - 2002-11-12 17:18:04
|
On Tue, 12 Nov 2002, Rick Wash wrote: > char volitile *key; actually the standard says this can be ignored, IIRC. hence, it can be optimized away. gcc 3.2 does, for example. as for libevent: we use it at work to avoid being multithreaded and use it to handle a shit ton of data. scaling problems are typically not a problem. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Rick W. <rw...@ci...> - 2002-11-12 17:14:36
|
[ replying to the whole thread ] > some implementation ideas: > > > - rely on systrace's priv elevation rather than being > > root/droppriv or even privsep Agreed. Not even supporting a non-systrace setup is not a bad idea. Forces the admins to learn and use systrace (though hinders the acceptance of unbound) > > - be single threaded but use libevent to drive the system I am not so sure about this one. libevent, definately. libevent is a great way to handle such things (especially with a kqueue backend). But if this is going to scale up to handle large DNS servers, being multithreaded is not a bad idea. However it doesn't have to be done right away. I say we get the single-threaded stuff working first, remembering to try to keep everything thread-safe, and then later worry about multithreading. > > - start with ipv4, but be ready for ipv6 > sounds good to me. the ipv6 thing is about data and record design. no > sense scrapping stuff for ipv6 unless you recognize that from the start. Agreed. We can get ipv4 working first, trying hard to avoid assumptions such as header-length and such as the ip address fits in an integer, and then later we can worry about ipv6. > > - use openssl for dnssec stuff > so the issue there isn't that they're not using openssl, its that they're > just mucking it a bit funnily. i dont trust their seeding, Me neither. I say openssl is much better. > i dont trust their key management in memory after the whole > memset 0 thing this past week ... I don't know about this one. There is a pretty simple fix to this -- make the memory 'volitile'. aka char volitile *key; That way, the compiler will not be able to optimize out such operations as memset(0). However, we definately need to check for this everywhere. > > so the real question is where does one start? at full current standards > > and attempt to implement them (an intractable task, to be sure) or > > basically start out with bind 4 and add features as needed (dnssec, ipv6)? > > luckily bind9 is under a bsd license ... :) > The BIND4 feature set seems a good first goal, since we can maybe get it > in to current at that point to replace the old bind... Agreed. If we can get it to the point where we can use it in the real world, that would be impressive and good. Rick |
|
From: Jose N. <jo...@mo...> - 2002-11-12 16:55:44
|
On Tue, 12 Nov 2002, Lurene Angela Grenier wrote: > Hells yeah - that was the suggestion I had last night - then you can > just do thurough checks on the input to the functions that are elevated, > and take the input through lowered functions. lemme properly credit the idea to lurene :) > If the crypto is as bad as you say it is it's probably not a bad idea. so the issue there isn't that they're not using openssl, its that they're just mucking it a bit funnily. i dont trust their seeding, i dont trust their key management in memory after the whole memset 0 thing this past week ... > The BIND4 feature set seems a good first goal, since we can maybe get it > in to current at that point to replace the old bind... sounds good to me. the ipv6 thing is about data and record design. no sense scrapping stuff for ipv6 unless you recognize that from the start. ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Lurene A. G. <lu...@da...> - 2002-11-12 16:52:13
|
> - rely on systrace's priv elevation rather than being
> root/droppriv or even privsep
Hells yeah - that was the suggestion I had last night - then you can just
do thurough checks on the input to the functions that are elevated, and
take the input through lowered functions.
> - start with ipv4, but be ready for ipv6
I think we could get ipv6 in there from the start.
> - use openssl for dnssec stuff
If the crypto is as bad as you say it is it's probably not a bad idea.
>
> so the real question is where does one start? at full current standards
> and attempt to implement them (an intractable task, to be sure) or
> basically start out with bind 4 and add features as needed (dnssec, ipv6)?
> luckily bind9 is under a bsd license ... :)
The BIND4 feature set seems a good first goal, since we can maybe get it
in to current at that point to replace the old bind...
Lurene
--
"What I cannot create, I cannot understand"
-- Richard Feynman
|
|
From: Jose N. <jo...@mo...> - 2002-11-12 16:30:06
|
On Tue, 12 Nov 2002, Lurene Angela Grenier wrote: > While the code base is rather large and imposing I'm still thinking that > it would be beneficial to rewrite at least a portion of the code over > from scratch. Such things like dig can be done very simply with getopt, > and I think a quick review would show that a LARGE part of the code is > wheel reinvention and can be cut, so that even if we use the general > BIND9 layout, we can still cut down alot of code and get a much better > piece of software. the answer, lurene, lies in your .sig: > "What I cannot create, I cannot understand" > -- Richard Feynman this is precisely the reason why i think it's worth it to redo it from scratch. i, too, have been overwhelmed with the codebase. isc poorly reimplemented a lot of stuff. refactoring is a challenging task. some implementation ideas: - rely on systrace's priv elevation rather than being root/droppriv or even privsep - be single threaded but use libevent to drive the system - start with ipv4, but be ready for ipv6 - use openssl for dnssec stuff so the real question is where does one start? at full current standards and attempt to implement them (an intractable task, to be sure) or basically start out with bind 4 and add features as needed (dnssec, ipv6)? luckily bind9 is under a bsd license ... :) ___________________________ jose nazario, ph.d. jo...@mo... http://www.monkey.org/~jose/ |
|
From: Lurene A. G. <lu...@da...> - 2002-11-12 16:19:31
|
While the code base is rather large and imposing I'm still thinking
that it would be beneficial to rewrite at least a portion of the code over
from scratch. Such things like dig can be done very simply with getopt, and
I think a quick review would show that a LARGE part of the code is wheel
reinvention and can be cut, so that even if we use the general BIND9
layout, we can still cut down alot of code and get a much better piece of
software.
Thoughts?
Lurene
--
"What I cannot create, I cannot understand"
-- Richard Feynman
|
|
From: Rick W. <rw...@ci...> - 2002-11-11 02:36:41
|
On Sun, Nov 10, 2002 at 08:32:16PM -0500, Jose Nazario wrote: > i truncated our numbers by two: ben and chris. Good idea. I don't think they ever did anything, unfortunately. > rick has done some work (obviously, he just reviewed a patch real > quick) yeah. Unfortunately, with grad school I don't have much time to do any actual coding, but I am happy to review patches and such sent out by the list. I can find time for such activities. And maybe one or two days of actual hacking :) > ... floh is supposedly doing some docs. Cool. We definately need those. > we added one, too: lurene, from openbsd. she's pretty damned tenacious at > code audits. Good choice. Welcome Lurene. Fresh blood in the project will be helpful. > the more i think about it, the most i dislike isc products. they (poorly) > reinvent libc. Agreed. They did this for compatibility reasons. They wanted it to run everywhere. But since we are restricting ourselves to a single (or a few) platforms, most of this can go. Rick |
