Re: dc(1); fix 0Z
On Sat, 02 Dec 2017 07:50:35 +, Otto Moerbeek wrote: > Spotted while working on kshe's diff. > > Makes Z0p work the same as both gnu dc and the orignal dc. > > OK? I guess you probably mean `0Zp', and in that case a mere return n->scale; should suffice here. Also, the manual defines the length of a number as its number of digits, so perhaps it should be precised that zero is considered to have no digits, which might not be obvious to everyone. Other than that, I think this makes more sense indeed. Regards, kshe
Re: dc(1); fix 0Z
On Sat, Dec 02, 2017 at 10:38:00AM +, kshe wrote: > On Sat, 02 Dec 2017 07:50:35 +, Otto Moerbeek wrote: > > Spotted while working on kshe's diff. > > > > Makes Z0p work the same as both gnu dc and the orignal dc. > > > > OK? > > I guess you probably mean `0Zp', and in that case a mere > > return n->scale; > > should suffice here. > > Also, the manual defines the length of a number as its number of digits, > so perhaps it should be precised that zero is considered to have no > digits, which might not be obvious to everyone. > > Other than that, I think this makes more sense indeed. > > Regards, > > kshe Yeah, you're three times right, thanks, -Otto
Re: gettimeofday(2) does not conform to POSIX.1-2008?
On Sat, Dec 02, 2017 at 11:54:23AM -0700, Theo de Raadt wrote: > > > Wouldn't be the first error in POSIX. The documents have gotten > > > sloppier. I think this is due to their commitee not acquiring any > > > sensible young blood. > > > > fwiw, the "return zero and only zero" behavior traces back at least > > as far as here (SUSv2, I think): > > > > http://pubs.opengroup.org/onlinepubs/7908799/xsh/gettimeofday.html > > > > so if it's an error it isn't a "new" error. > > Hang on, you say behavior. > > Behavior is a quality of implementation. If you research back to the > dawn of time, gettimeofday would return -1 and EFAULT because it uses > a kernel function copyout(9) to do it's work, or maybe even earlier > a pair of suword calls with the same error return. > > Implementation leads to that behavior. > > Did someone do it differently? Maybe, but developers need to know > that passing an invalid pointer can result in an error return rather > than some weird fault. > > The POSIX document is a descriptive document. It should describe the > existing behavior to enhance compatibility. There are strategies for > how one may describe a behavior: minimally or maximally, with impacts > on readership in all directions. This instance shows they prefer to > be minimally descriptive or dare I say it -- inaccurate by omission. > They may have some goal in mind, but it still is inaccurate, and their > justifications are kept largely secret. It is a secretive cabal, and > don't point me to austin-group lists, it is nothing more than lipstick > on a pig. > > When descriptive documents willfully describe a system incompletely, > it makes it harder for software developers to consider them as a > proscriptive or leading agency. Errors result. How apropos that I write "behavior" when I meant "wording." Point well taken. -- Scott Cheloha
Re: gettimeofday(2) does not conform to POSIX.1-2008?
On Sat, Dec 02, 2017 at 11:05:17AM -0700, Theo de Raadt wrote: > > TL;DR: POSIX.1-2008 says gettimeofday(2) can't return anything but 0, > > but we return -1 on invalid input. > > It must return -1 to indicate the tp pointer is to invalid memory. > All system calls indicate invalid pointer arguments in that way, and > this one is not special. > > [EFAULT] An argument address referenced invalid memory. > > > We claim that our gettimeofday(2) conforms to POSIX.1-2008. Is > > something off here? > > POSIX appears to be wrong. > > Yes there are people doing VDSO things, which may not be able to > indicate a fault, and the process will crash instead when it fondles > it's own missing memory. But I don't see any way that gives the > commitee latitude to remove historic behaviour. > > > Also, gettimeofday(2) is an XSI extension, so I think at a > > minimum the STANDARDS section needs to be tweaked (attached). > > As a general rule we don't speak of XSI unless it exposes programmers > to problems. Ah, okay. > Mentioning XSI in the way you propose doesn't actually > help anyone write better code since noone knows what XSI is. So in > this case, I don't think XSI should be mentioned, the words perform > no educational function. Alrighty. > > Long version: > > > > POSIX.1-2008 [1] says: > > > > > The gettimeofday() function shall return 0 and no value shall > > > be reserved to indicate an error. > > Wouldn't be the first error in POSIX. The documents have gotten > sloppier. I think this is due to their commitee not acquiring any > sensible young blood. fwiw, the "return zero and only zero" behavior traces back at least as far as here (SUSv2, I think): http://pubs.opengroup.org/onlinepubs/7908799/xsh/gettimeofday.html so if it's an error it isn't a "new" error. > > Does this make our implementation non-conforming and does something > > in the manpage need to change? > > I don't think anything should change. Okay. Appreciate the quick reply! -- Scott Cheloha
gettimeofday(2) does not conform to POSIX.1-2008?
Hi, TL;DR: POSIX.1-2008 says gettimeofday(2) can't return anything but 0, but we return -1 on invalid input. We claim that our gettimeofday(2) conforms to POSIX.1-2008. Is something off here? Also, gettimeofday(2) is an XSI extension, so I think at a minimum the STANDARDS section needs to be tweaked (attached). Long version: POSIX.1-2008 [1] says: > The gettimeofday() function shall return 0 and no value shall > be reserved to indicate an error. where "shall" is defined [2] as: > For an implementation that conforms to POSIX.1-2008, describes a > feature or behavior that is mandatory. [...] But in our own gettimeofday(2): > Upon successful completion, the value 0 is returned; otherwise the > value -1 is returned and the global variable errno is set to indicate > the error. and looking at kern/kern_time.c, this is the case. Does this make our implementation non-conforming and does something in the manpage need to change? I do note that gettimeofday(2) predates [3] POSIX (and me :p), so perhaps this is just an ancient compromise between BSD and the standards committees? Thoughts? -- Scott Cheloha [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html#tag_01_05_05 [3] https://github.com/dspinellis/unix-history-repo/blob/BSD-4_1c_2-Snapshot-Development/usr/man/man2/gettimeofday.2 Index: lib/libc/sys/gettimeofday.2 === RCS file: /cvs/src/lib/libc/sys/gettimeofday.2,v retrieving revision 1.29 diff -u -p -r1.29 gettimeofday.2 --- lib/libc/sys/gettimeofday.2 10 Sep 2015 17:55:21 - 1.29 +++ lib/libc/sys/gettimeofday.2 2 Dec 2017 17:38:40 - @@ -133,8 +133,10 @@ A user other than the superuser attempte .Sh STANDARDS The .Fn gettimeofday -function conforms to -.St -p1003.1-2008 . +function conforms to the +X/Open System Interfaces option of the +.St -p1003.1-2008 +specification. .Sh HISTORY As predecessors of these functions, former system calls .Fn time
mess with regression tests
Hello, openbsd has a regression testuite in a base tree. Testset for each component is in a separate directory, Makefiles for each testsuite uses bsd.regress.mk framework and connected to the root Makefile. So it is easy to run overall testsuite with 'make regress'. But tests for some utilities are placed with sources and not linked to Makefiles. Looks like it is dead, unusable code and broken tests. It means that no one never run these tests. I went through these abandoned tests: - bin/ed/test connected to the Makefile in a source directory, tests looks broken. - lib/libexpat/tests/ tests requires external unit testing framework (check). - usr.bin/sed/TEST directory contains several tests, but there no infrustructure to run them and files with expected results. Moreover the same tests are present in regress/usr.bin/sed dir. - gnu/usr.bin/binutils/gdb/testsuite test suite requires dejagnu package from ports, it is not connected to the Makefile in sources and tests have many fails (about a couple of hundreds). - usr.bin/m4/TEST dir contains examples of m4 files not tests, Makefile is absent. Similar situation with these tests: - gnu/usr.bin/gcc/gcc/testsuite - usr.bin/ctags/test - lib/libssl/test - lib/libkeynote/testsuite Are there real reasons to keep these tests separately? Sergey
iked: set flag if we send more proposals
Hi,
if we wanted to send out more proposals than just one, we need to set a
flag in the SA header that there is another proposal coming. The "more"
attribute borrows its values, as specified in the RFC, from IKEv1.
ok?
Patrick
diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c
index 062b6a50b40..957e52f37a8 100644
--- a/sbin/iked/ikev2.c
+++ b/sbin/iked/ikev2.c
@@ -2023,6 +2023,7 @@ ikev2_add_proposals(struct iked *env, struct iked_sa *sa,
struct ibuf *buf,
} else
nxforms = prop->prop_nxforms;
+ sap->sap_more = IKEV1_PAYLOAD_PROPOSAL;
sap->sap_proposalnr = prop->prop_id;
sap->sap_protoid = prop->prop_protoid;
sap->sap_spisize = prop->prop_localspi.spi_size;
@@ -2066,6 +2067,8 @@ ikev2_add_proposals(struct iked *env, struct iked_sa *sa,
struct ibuf *buf,
sap->sap_length = htobe16(saplength);
length += saplength;
}
+ if (sap != NULL)
+ sap->sap_more = IKEV1_PAYLOAD_NONE;
log_debug("%s: length %zd", __func__, length);
diff --git a/sbin/iked/ikev2.h b/sbin/iked/ikev2.h
index 683fd47845d..d4b15245d24 100644
--- a/sbin/iked/ikev2.h
+++ b/sbin/iked/ikev2.h
@@ -527,4 +527,8 @@ struct ikev2_cfg {
extern struct iked_constmap ikev2_cfg_map[];
+/* IKEv1 payload types */
+#define IKEV1_PAYLOAD_NONE 0 /* No payload */
+#define IKEV1_PAYLOAD_PROPOSAL 2 /* Proposal */
+
#endif /* IKED_IKEV2_H */
Re: diff: cu(1): add secure kiosk mode + stricter pledge
On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > The diff adds the option -k (for kiosk mode)
>
> Congratulations, you win some sort of prize. That is the worst-named
> option I have seen in more than a decade.
Thanks. :-)
> Good idea though, but I think we have better getopt interfaces for
> blocking escapes in other commands. ssh has to do this, and I suspect
> a few other commands do also.
>
> So two comments: Calling this thing by the right name (escape),
> would allow you to search other programs which have similar functions,
> see if someone did it before, and match the behaviour / option.
Yes, the term "kiosk mode" is not that common in unix environments.
So, I changed it to "restricted mode" as it is used in ksh(1).
Thanks,
Jan
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c 5 Oct 2015 23:15:31 - 1.15
+++ command.c 2 Dec 2017 18:02:20 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+ if (r_flag) {
+ cu_warnx("~C command is not allowed in kiosk mode");
+ break;
+ }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+ if (r_flag) {
+ cu_warnx("~R command is not allowed in kiosk mode");
+ break;
+ }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+ if (r_flag) {
+ cu_warnx("~X command is not allowed in kiosk mode");
+ break;
+ }
send_xmodem();
break;
case '$':
+ if (r_flag) {
+ cu_warnx("~$ command is not allowed in kiosk mode");
+ break;
+ }
pipe_command();
break;
case '>':
+ if (r_flag) {
+ cu_warnx("~> command is not allowed in kiosk mode");
+ break;
+ }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 - 1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl d
+.Op Fl dr
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,11 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
The command string sent to the local
.Ux
system is processed by the shell.
+This command is not allowed in restricted mode.
.It Ic ~#
Send a
.Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
1 \*(Lt-\*(Gt remote tty out
2 \*(Lt-\*(Gt local tty stderr
.Ed
+.Pp
+This command is not allowed in restricted mode.
.It Ic ~D
Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
.It Ic ~R
Record all output from the remote system to a file.
If the given file already exists, it is appended to.
If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
.It Ic ~S
Change the speed of the connection.
.It Ic ~X
Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
.It Ic ~?
Get a summary of the tilde escapes.
.El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 - 1.25
+++ cu.c2 Dec 2017 18:02:06 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
int is_direct = -1;
+int r_flag = 0;
const char *line_path = NULL;
int line_speed = -1;
int line_fd;
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+ fprintf(stderr, "usage: %s [-dk] [-l line] [-s speed
Re: diff: cu(1): add secure kiosk mode + stricter pledge
On Sat, Dec 02, 2017 at 08:17:15PM +0100, Jan Klemkow wrote:
> On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > So two comments: Calling this thing by the right name (escape),
> > would allow you to search other programs which have similar functions,
> > see if someone did it before, and match the behaviour / option.
>
> Yes, the term "kiosk mode" is not that common in unix environments.
> So, I changed it to "restricted mode" as it is used in ksh(1).
Sorry for the noise. I forget to change the warning messages. I also
changed the variable r_flag to "restricted" as it is used in the source
of ksh(1), too.
This version should be fine:
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c 5 Oct 2015 23:15:31 - 1.15
+++ command.c 2 Dec 2017 19:30:52 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+ if (restricted) {
+ cu_warnx("~C command is not allowed in restricted
mode");
+ break;
+ }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+ if (restricted) {
+ cu_warnx("~R command is not allowed in restricted
mode");
+ break;
+ }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+ if (restricted) {
+ cu_warnx("~X command is not allowed in restricted
mode");
+ break;
+ }
send_xmodem();
break;
case '$':
+ if (restricted) {
+ cu_warnx("~$ command is not allowed in restricted
mode");
+ break;
+ }
pipe_command();
break;
case '>':
+ if (restricted) {
+ cu_warnx("~> command is not allowed in restricted
mode");
+ break;
+ }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 - 1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl d
+.Op Fl dr
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,11 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
The command string sent to the local
.Ux
system is processed by the shell.
+This command is not allowed in restricted mode.
.It Ic ~#
Send a
.Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
1 \*(Lt-\*(Gt remote tty out
2 \*(Lt-\*(Gt local tty stderr
.Ed
+.Pp
+This command is not allowed in restricted mode.
.It Ic ~D
Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
.It Ic ~R
Record all output from the remote system to a file.
If the given file already exists, it is appended to.
If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
.It Ic ~S
Change the speed of the connection.
.It Ic ~X
Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
.It Ic ~?
Get a summary of the tilde escapes.
.El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 - 1.25
+++ cu.c2 Dec 2017 19:28:52 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
int is_direct = -1;
+int restricted = 0;
const char *line_path = NULL;
int line_speed = -1;
int line_fd;
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+ fprintf(stderr, "usage: %s [-dk] [-l line] [-s speed | -speed]\n",
__progname);
Re: gettimeofday(2) does not conform to POSIX.1-2008?
> TL;DR: POSIX.1-2008 says gettimeofday(2) can't return anything but 0, > but we return -1 on invalid input. It must return -1 to indicate the tp pointer is to invalid memory. All system calls indicate invalid pointer arguments in that way, and this one is not special. [EFAULT] An argument address referenced invalid memory. > We claim that our gettimeofday(2) conforms to POSIX.1-2008. Is > something off here? POSIX appears to be wrong. Yes there are people doing VDSO things, which may not be able to indicate a fault, and the process will crash instead when it fondles it's own missing memory. But I don't see any way that gives the commitee latitude to remove historic behaviour. > Also, gettimeofday(2) is an XSI extension, so I think at a > minimum the STANDARDS section needs to be tweaked (attached). As a general rule we don't speak of XSI unless it exposes programmers to problems. Mentioning XSI in the way you propose doesn't actually help anyone write better code since noone knows what XSI is. So in this case, I don't think XSI should be mentioned, the words perform no educational function. > Long version: > > POSIX.1-2008 [1] says: > > > The gettimeofday() function shall return 0 and no value shall > > be reserved to indicate an error. Wouldn't be the first error in POSIX. The documents have gotten sloppier. I think this is due to their commitee not acquiring any sensible young blood. > Does this make our implementation non-conforming and does something > in the manpage need to change? I don't think anything should change.
Re: gettimeofday(2) does not conform to POSIX.1-2008?
> > Wouldn't be the first error in POSIX. The documents have gotten > > sloppier. I think this is due to their commitee not acquiring any > > sensible young blood. > > fwiw, the "return zero and only zero" behavior traces back at least > as far as here (SUSv2, I think): > > http://pubs.opengroup.org/onlinepubs/7908799/xsh/gettimeofday.html > > so if it's an error it isn't a "new" error. Hang on, you say behavior. Behavior is a quality of implementation. If you research back to the dawn of time, gettimeofday would return -1 and EFAULT because it uses a kernel function copyout(9) to do it's work, or maybe even earlier a pair of suword calls with the same error return. Implementation leads to that behavior. Did someone do it differently? Maybe, but developers need to know that passing an invalid pointer can result in an error return rather than some weird fault. The POSIX document is a descriptive document. It should describe the existing behavior to enhance compatibility. There are strategies for how one may describe a behavior: minimally or maximally, with impacts on readership in all directions. This instance shows they prefer to be minimally descriptive or dare I say it -- inaccurate by omission. They may have some goal in mind, but it still is inaccurate, and their justifications are kept largely secret. It is a secretive cabal, and don't point me to austin-group lists, it is nothing more than lipstick on a pig. When descriptive documents willfully describe a system incompletely, it makes it harder for software developers to consider them as a proscriptive or leading agency. Errors result.
