Re: md5/sha256 -c option
On Fri, Jan 10, 2014 at 12:54:20AM -0700, Theo de Raadt wrote: > > On Fri, Jan 10, 2014 at 12:13:45AM -0500, Ted Unangst wrote: > > > The synopsis for -c is dreadfully confusing. it's a mode, not an > > > option. as such, all the other stuff isn't available. > > > > > > > i see it's already done, so i'm late to the party. but i'll add my > > thoughts anyway. > > > > i dislike this. i dislike splitting SYNOPSIS up. it is not SYNOPSIS' job > > to tell you how to to use a utility. it is the text in the man page that > > is meant to do that. > > > > what's the problem? why, take a gander over to ssh-keygen(1) and see the > > way our pages are headed. see? yuck. and it's not just that - the syntax > > is simply not good enough to allow us to describe every permutation. > > you're just rewriting a lie. SYNOPSIS always lies. i don;t see why folks > > have such a hard time accepting this. > > > > so the problem is your method does appear, on the surface, clearer for > > simple usage cases. but when the utility gets more complex, it gets very > > ugly. so then we're left with some pages do it one way, others do it > > another way. and extra verbosity. > > > > i hate it. > > Well, three of us got fooled by it in one day. > > try this: > > sha -c SHA256 * > > What does it do? It does something very unexpected. > > Another option we can go to is: > > md5 [-bprtxc] [-h hashfile] [-s string] [file ...] > > Because -c DOES NOT TAKE A LIST OF FILES! > > 'c' is just a mode change, and then the file list at the end > means something entirely different. > > From the code: > >optstr = "bch:pqrs:tx"; > > See? It is c, not c: well then this means the description of -c is very poor. i would look for a fix there, not in SYNOPSIS. jmc
Re: md5/sha256 -c option
> On Fri, Jan 10, 2014 at 12:13:45AM -0500, Ted Unangst wrote: > > The synopsis for -c is dreadfully confusing. it's a mode, not an > > option. as such, all the other stuff isn't available. > > > > i see it's already done, so i'm late to the party. but i'll add my > thoughts anyway. > > i dislike this. i dislike splitting SYNOPSIS up. it is not SYNOPSIS' job > to tell you how to to use a utility. it is the text in the man page that > is meant to do that. > > what's the problem? why, take a gander over to ssh-keygen(1) and see the > way our pages are headed. see? yuck. and it's not just that - the syntax > is simply not good enough to allow us to describe every permutation. > you're just rewriting a lie. SYNOPSIS always lies. i don;t see why folks > have such a hard time accepting this. > > so the problem is your method does appear, on the surface, clearer for > simple usage cases. but when the utility gets more complex, it gets very > ugly. so then we're left with some pages do it one way, others do it > another way. and extra verbosity. > > i hate it. Well, three of us got fooled by it in one day. try this: sha -c SHA256 * What does it do? It does something very unexpected. Another option we can go to is: md5 [-bprtxc] [-h hashfile] [-s string] [file ...] Because -c DOES NOT TAKE A LIST OF FILES! 'c' is just a mode change, and then the file list at the end means something entirely different. >From the code: optstr = "bch:pqrs:tx"; See? It is c, not c:
Re: md5/sha256 -c option
On Fri, Jan 10, 2014 at 12:13:45AM -0500, Ted Unangst wrote: > The synopsis for -c is dreadfully confusing. it's a mode, not an > option. as such, all the other stuff isn't available. > i see it's already done, so i'm late to the party. but i'll add my thoughts anyway. i dislike this. i dislike splitting SYNOPSIS up. it is not SYNOPSIS' job to tell you how to to use a utility. it is the text in the man page that is meant to do that. what's the problem? why, take a gander over to ssh-keygen(1) and see the way our pages are headed. see? yuck. and it's not just that - the syntax is simply not good enough to allow us to describe every permutation. you're just rewriting a lie. SYNOPSIS always lies. i don;t see why folks have such a hard time accepting this. so the problem is your method does appear, on the surface, clearer for simple usage cases. but when the utility gets more complex, it gets very ugly. so then we're left with some pages do it one way, others do it another way. and extra verbosity. i hate it. jmc > Index: md5.1 > === > RCS file: /cvs/src/bin/md5/md5.1,v > retrieving revision 1.36 > diff -u -p -r1.36 md5.1 > --- md5.1 8 Jan 2014 16:12:44 - 1.36 > +++ md5.1 10 Jan 2014 05:08:51 - > @@ -26,11 +26,13 @@ > .Nd calculate a message digest (checksum) for a file > .Sh SYNOPSIS > .Nm md5 > -.Op Fl bpqrtx > -.Op Fl c Op Ar checklist ... > +.Op Fl bprtx > .Op Fl h Ar hashfile > .Op Fl s Ar string > .Op Ar > +.Nm md5 > +.Op Fl q > +.Fl c Op Ar checklist ... > .Sh DESCRIPTION > .Nm > takes as input a message of arbitrary length and produces > Index: md5.c > === > RCS file: /cvs/src/bin/md5/md5.c,v > retrieving revision 1.64 > diff -u -p -r1.64 md5.c > --- md5.c 8 Jan 2014 16:23:21 - 1.64 > +++ md5.c 10 Jan 2014 05:12:01 - > @@ -820,8 +820,10 @@ usage(void) > __progname, (int)strlen(__progname), ""); > else > #endif /* !defined(SMALL) */ > - fprintf(stderr, "usage: %s [-bpqrtx] [-c [checklist ...]] " > - "[-h hashfile] [-s string] [file ...]\n", __progname); > + fprintf(stderr, "usage:" > + "\t%s [-bprtx] [-h hashfile] [-s string] [file ...]\n" > + "\t%s [-q] -c [checklist ...]\n", > + __progname, __progname); > > exit(EXIT_FAILURE); > } > Index: sha1.1 > === > RCS file: /cvs/src/bin/md5/sha1.1,v > retrieving revision 1.34 > diff -u -p -r1.34 sha1.1 > --- sha1.18 Jan 2014 16:12:44 - 1.34 > +++ sha1.110 Jan 2014 05:09:06 - > @@ -26,11 +26,13 @@ > .Nd calculate a message digest (checksum) for a file > .Sh SYNOPSIS > .Nm sha1 > -.Op Fl bpqrtx > -.Op Fl c Op Ar checklist ... > +.Op Fl bprtx > .Op Fl h Ar hashfile > .Op Fl s Ar string > .Op Ar > +.Nm sha1 > +.Op Fl q > +.Fl c Op Ar checklist ... > .Sh DESCRIPTION > .Nm > takes as input a message of arbitrary length and produces > Index: sha256.1 > === > RCS file: /cvs/src/bin/md5/sha256.1,v > retrieving revision 1.9 > diff -u -p -r1.9 sha256.1 > --- sha256.1 8 Jan 2014 16:12:44 - 1.9 > +++ sha256.1 10 Jan 2014 05:09:47 - > @@ -27,17 +27,21 @@ > .Nd calculate a message digest (checksum) for a file > .Sh SYNOPSIS > .Nm sha256 > -.Op Fl bpqrtx > -.Op Fl c Op Ar checklist ... > +.Op Fl bprtx > .Op Fl h Ar hashfile > .Op Fl s Ar string > .Op Ar > +.Nm sha256 > +.Op Fl q > +.Fl c Op Ar checklist ... > .Nm sha512 > -.Op Fl bpqrtx > -.Op Fl c Op Ar checklist ... > +.Op Fl bprtx > .Op Fl h Ar hashfile > .Op Fl s Ar string > .Op Ar > +.Nm sha512 > +.Op Fl q > +.Fl c Op Ar checklist ... > .Sh DESCRIPTION > .Nm > takes as input a message of arbitrary length and produces > >
Re: remove kcopy
> > The only caller of kcopy is uiomove. There is no way a function like > > this can ever work. If you need to rely on your copy function to save > > you from pointers outside the address space, it means you don't know > > what garbage you're passing it. Meaning you may well be passing it > > pointers inside the address space, but to something unexpected, which > > you will then shit on. > > > > Replace with memcpy. > > Vetoed. > > kcopy() is not only used to move data from the kernel data section to > the kernel data section. > > It is used to move data *within the kernel address space* to data > *within the kernel address space*. Think dd if=/dev/mem ... If the range checks are important, should the entire thing not be rewritten in C, then call memcpy upon success?
md5/sha256 -c option
The synopsis for -c is dreadfully confusing. it's a mode, not an option. as such, all the other stuff isn't available. Index: md5.1 === RCS file: /cvs/src/bin/md5/md5.1,v retrieving revision 1.36 diff -u -p -r1.36 md5.1 --- md5.1 8 Jan 2014 16:12:44 - 1.36 +++ md5.1 10 Jan 2014 05:08:51 - @@ -26,11 +26,13 @@ .Nd calculate a message digest (checksum) for a file .Sh SYNOPSIS .Nm md5 -.Op Fl bpqrtx -.Op Fl c Op Ar checklist ... +.Op Fl bprtx .Op Fl h Ar hashfile .Op Fl s Ar string .Op Ar +.Nm md5 +.Op Fl q +.Fl c Op Ar checklist ... .Sh DESCRIPTION .Nm takes as input a message of arbitrary length and produces Index: md5.c === RCS file: /cvs/src/bin/md5/md5.c,v retrieving revision 1.64 diff -u -p -r1.64 md5.c --- md5.c 8 Jan 2014 16:23:21 - 1.64 +++ md5.c 10 Jan 2014 05:12:01 - @@ -820,8 +820,10 @@ usage(void) __progname, (int)strlen(__progname), ""); else #endif /* !defined(SMALL) */ - fprintf(stderr, "usage: %s [-bpqrtx] [-c [checklist ...]] " - "[-h hashfile] [-s string] [file ...]\n", __progname); + fprintf(stderr, "usage:" + "\t%s [-bprtx] [-h hashfile] [-s string] [file ...]\n" + "\t%s [-q] -c [checklist ...]\n", + __progname, __progname); exit(EXIT_FAILURE); } Index: sha1.1 === RCS file: /cvs/src/bin/md5/sha1.1,v retrieving revision 1.34 diff -u -p -r1.34 sha1.1 --- sha1.1 8 Jan 2014 16:12:44 - 1.34 +++ sha1.1 10 Jan 2014 05:09:06 - @@ -26,11 +26,13 @@ .Nd calculate a message digest (checksum) for a file .Sh SYNOPSIS .Nm sha1 -.Op Fl bpqrtx -.Op Fl c Op Ar checklist ... +.Op Fl bprtx .Op Fl h Ar hashfile .Op Fl s Ar string .Op Ar +.Nm sha1 +.Op Fl q +.Fl c Op Ar checklist ... .Sh DESCRIPTION .Nm takes as input a message of arbitrary length and produces Index: sha256.1 === RCS file: /cvs/src/bin/md5/sha256.1,v retrieving revision 1.9 diff -u -p -r1.9 sha256.1 --- sha256.18 Jan 2014 16:12:44 - 1.9 +++ sha256.110 Jan 2014 05:09:47 - @@ -27,17 +27,21 @@ .Nd calculate a message digest (checksum) for a file .Sh SYNOPSIS .Nm sha256 -.Op Fl bpqrtx -.Op Fl c Op Ar checklist ... +.Op Fl bprtx .Op Fl h Ar hashfile .Op Fl s Ar string .Op Ar +.Nm sha256 +.Op Fl q +.Fl c Op Ar checklist ... .Nm sha512 -.Op Fl bpqrtx -.Op Fl c Op Ar checklist ... +.Op Fl bprtx .Op Fl h Ar hashfile .Op Fl s Ar string .Op Ar +.Nm sha512 +.Op Fl q +.Fl c Op Ar checklist ... .Sh DESCRIPTION .Nm takes as input a message of arbitrary length and produces
Re: remove kcopy
> The only caller of kcopy is uiomove. There is no way a function like > this can ever work. If you need to rely on your copy function to save > you from pointers outside the address space, it means you don't know > what garbage you're passing it. Meaning you may well be passing it > pointers inside the address space, but to something unexpected, which > you will then shit on. > > Replace with memcpy. Vetoed. kcopy() is not only used to move data from the kernel data section to the kernel data section. It is used to move data *within the kernel address space* to data *within the kernel address space*. Think dd if=/dev/mem ... Miod
Re: remove kcopy
On Fri, Jan 10, 2014 at 05:14, Miod Vallat wrote: >> The only caller of kcopy is uiomove. There is no way a function like >> this can ever work. If you need to rely on your copy function to save >> you from pointers outside the address space, it means you don't know >> what garbage you're passing it. Meaning you may well be passing it >> pointers inside the address space, but to something unexpected, which >> you will then shit on. >> >> Replace with memcpy. > > Vetoed. > > kcopy() is not only used to move data from the kernel data section to > the kernel data section. > > It is used to move data *within the kernel address space* to data > *within the kernel address space*. Think dd if=/dev/mem ... isn't that an example of kernel address space to userland? i did dig around a bit into uvm_io and callers, but didn't see anything that depended on kcopy fault protection. there were some comments indicating it is perhaps a holdover from swappable upage?
tcpdrop(8): check strdup() return values
This checks the return values of strdup() calls in tcpdrop(8).
OK?
Index: tcpdrop.c
===
RCS file: /cvs/src/usr.sbin/tcpdrop/tcpdrop.c,v
retrieving revision 1.12
diff -u -p -r1.12 tcpdrop.c
--- tcpdrop.c 24 Oct 2013 02:55:50 - 1.12
+++ tcpdrop.c 9 Jan 2014 22:50:43 -
@@ -54,6 +54,8 @@ main(int argc, char **argv)
if (argc == 3) {
laddr1 = addr1 = strdup(argv[1]);
+ if (!addr1)
+ err(1, "strdup");
port1 = strrchr(addr1, ':');
if (port1)
*port1++ = '\0';
@@ -61,6 +63,8 @@ main(int argc, char **argv)
goto fail;
faddr2 = addr2 = strdup(argv[2]);
+ if (!addr2)
+ err(1, "strdup");
port2 = strrchr(addr2, ':');
if (port2)
*port2++ = '\0';
@@ -84,11 +88,15 @@ fail:
if (addr1[0] == '[' && addr1[strlen(addr1) - 1] == ']') {
laddr1 = strdup(addr1);
+ if (!laddr1)
+ err(1, "strdup");
laddr1[strlen(laddr1) - 1] = '\0';
laddr1++;
}
if (addr2[0] == '[' && addr2[strlen(addr2) - 1] == ']') {
faddr2 = strdup(addr2);
+ if (!faddr2)
+ err(1, "strdup");
faddr2[strlen(faddr2) - 1] = '\0';
faddr2++;
}
remove kcopy
The only caller of kcopy is uiomove. There is no way a function like this can ever work. If you need to rely on your copy function to save you from pointers outside the address space, it means you don't know what garbage you're passing it. Meaning you may well be passing it pointers inside the address space, but to something unexpected, which you will then shit on. Replace with memcpy. Not shown: the 200 line diff to remove kcopy from sparc64 locore.s. Index: kern/kern_subr.c === RCS file: /cvs/src/sys/kern/kern_subr.c,v retrieving revision 1.37 diff -u -p -r1.37 kern_subr.c --- kern/kern_subr.c19 Oct 2013 09:24:57 - 1.37 +++ kern/kern_subr.c9 Jan 2014 21:00:48 - @@ -88,11 +88,9 @@ uiomove(void *cp, int n, struct uio *uio case UIO_SYSSPACE: if (uio->uio_rw == UIO_READ) - error = kcopy(cp, iov->iov_base, cnt); + memcpy(iov->iov_base, cp, cnt); else - error = kcopy(iov->iov_base, cp, cnt); - if (error) - return(error); + memcpy(cp, iov->iov_base, cnt); } iov->iov_base = (caddr_t)iov->iov_base + cnt; iov->iov_len -= cnt; Index: sys/systm.h === RCS file: /cvs/src/sys/sys/systm.h,v retrieving revision 1.100 diff -u -p -r1.100 systm.h --- sys/systm.h 11 Jun 2013 18:15:54 - 1.100 +++ sys/systm.h 9 Jan 2014 21:02:04 - @@ -187,10 +187,6 @@ void assertwaitok(void); void tablefull(const char *); -intkcopy(const void *, void *, size_t) - __attribute__ ((__bounded__(__buffer__,1,3))) - __attribute__ ((__bounded__(__buffer__,2,3))); - void bcopy(const void *, void *, size_t) __attribute__ ((__bounded__(__buffer__,1,3))) __attribute__ ((__bounded__(__buffer__,2,3)));
rc default PF ruleset too restrictive for DHCPv6
The default PF ruleset as setup by rc is too restrictive. Have the default
ruleset allow for DHCPv6.
Index: rc
===
RCS file: /home/cvs/src/etc/rc,v
retrieving revision 1.419
diff -u -p -u -p -r1.419 rc
--- rc 3 Jan 2014 23:24:19 - 1.419
+++ rc 9 Jan 2014 20:47:07 -
@@ -330,6 +330,8 @@ if [ X"${pf}" != X"NO" ]; then
RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type
neighbradv"
RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type
routersol"
RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type
routeradv"
+ RULES="$RULES\npass out inet6 proto udp from any port
dhcpv6-client to any port dhcpv6-server"
+ RULES="$RULES\npass in inet6 proto udp from any port
dhcpv6-server to any port dhcpv6-client"
fi
RULES="$RULES\npass proto carp keep state (no-sync)"
case `sysctl vfs.mounts.nfs 2>/dev/null` in
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: awk(1) update
Miod Vallat writes:
>> So here's the same diff without the "negative 0.0" change.
>> Update which:
>> - marks some functions as __dead (instead of upstream
>> __attribute__((__noreturn__)))
>> - fixes split(a[1], a).
>>
>> ok?
>
> FIXES still lists the setfval change, which you did not include. It
> would make sense to omit this chunk from FIXES as well.
Tobias reminded me about this. Same diff, with a note added to FIXES.
I can completely get rid of that entry if people feel it's necessary.
A previous diff that included the "negative zero" change from upstream
had been successfuly tested in a ports bulk build (thanks to Landry),
I don't think this diff needs another bulk but YMMV.
ok?
Index: FIXES
===
RCS file: /cvs/src/usr.bin/awk/FIXES,v
retrieving revision 1.16
diff -u -p -r1.16 FIXES
--- FIXES 28 Sep 2011 19:27:18 - 1.16
+++ FIXES 9 Jan 2014 12:46:35 -
@@ -26,6 +26,22 @@ THIS SOFTWARE.
This file lists all bug fixes, changes, etc., made since the AWK book
was sent to the printers in August, 1987.
+Dec 20, 2012:
+ fiddled makefile to get correct yacc and bison flags. pick yacc
+ (linux) or bison (mac) as necessary.
+
+ added __attribute__((__noreturn__)) to a couple of lines in
+ proto.h, to silence someone's enthusiastic checker.
+
+ fixed obscure call by value bug in split(a[1],a) reported on
+ 9fans. the management of temporary values is just a mess; i
+ took a shortcut by making an extra string copy. thanks
+ to paul patience and arnold robbins for passing it on and for
+ proposed patches.
+
+ tiny fiddle in setfval to eliminate -0 results in T.expr, which
+ has irritated me for 20+ years. (not present on OpenBSD)
+
Aug 10, 2011:
another fix to avoid core dump with delete(ARGV); again, many thanks
to ruslan ermilov.
Index: main.c
===
RCS file: /cvs/src/usr.bin/awk/main.c,v
retrieving revision 1.17
diff -u -p -r1.17 main.c
--- main.c 28 Sep 2011 19:27:18 - 1.17
+++ main.c 22 Jun 2013 21:52:59 -
@@ -23,7 +23,7 @@ ARISING OUT OF OR IN CONNECTION WITH THE
THIS SOFTWARE.
/
-const char *version = "version 20110810";
+const char *version = "version 20121220";
#define DEBUG
#include
Index: proto.h
===
RCS file: /cvs/src/usr.bin/awk/proto.h,v
retrieving revision 1.9
diff -u -p -r1.9 proto.h
--- proto.h 28 Sep 2011 19:27:18 - 1.9
+++ proto.h 22 Jun 2013 21:36:31 -
@@ -47,7 +47,7 @@ externvoidfreetr(Node *);
extern int hexstr(uschar **);
extern int quoted(uschar **);
extern char*cclenter(const char *);
-extern voidoverflo(const char *);
+extern voidoverflo(const char *) __dead;
extern voidcfoll(fa *, Node *);
extern int first(Node *);
extern voidfollow(Node *);
@@ -133,7 +133,7 @@ extern voidfpecatch(int);
extern voidbracecheck(void);
extern voidbcheck2(int, int, int);
extern voidSYNTAX(const char *, ...);
-extern voidFATAL(const char *, ...);
+extern voidFATAL(const char *, ...) __dead;
extern voidWARNING(const char *, ...);
extern voiderror(void);
extern voideprint(void);
Index: run.c
===
RCS file: /cvs/src/usr.bin/awk/run.c,v
retrieving revision 1.34
diff -u -p -r1.34 run.c
--- run.c 29 Sep 2013 15:42:25 - 1.34
+++ run.c 21 Oct 2013 21:16:11 -
@@ -1218,13 +1218,13 @@ Cell *dopa2(Node **a, int n)/* a[0], a[
Cell *split(Node **a, int nnn) /* split(a[0], a[1], a[2]); a[3] is type */
{
Cell *x = 0, *y, *ap;
- char *s;
+ char *s, *origs;
int sep;
char *t, temp, num[50], *fs = 0;
int n, tempstat, arg3type;
y = execute(a[0]); /* source string */
- s = getsval(y);
+ origs = s = strdup(getsval(y));
arg3type = ptoi(a[3]);
if (a[2] == 0) /* fs string */
fs = *FS;
@@ -1344,6 +1344,7 @@ Cell *split(Node **a, int nnn)/* split(
}
tempfree(ap);
tempfree(y);
+ free(origs);
if (a[2] != 0 && arg3type == STRING) {
tempfree(x);
}
--
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
(previous: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494)
Patch to uftdi(4): update list of supported chips
Hi tech@ Here is an update to uftdi(4) that lists all the currently supported FTDI chips. Index: uftdi.4 === RCS file: /cvs/src/share/man/man4/uftdi.4,v retrieving revision 1.28 diff -u -p -r1.28 uftdi.4 --- uftdi.4 11 Sep 2012 16:04:43 - 1.28 +++ uftdi.4 9 Jan 2014 07:26:27 - @@ -40,8 +40,32 @@ .Sh DESCRIPTION The .Nm -driver provides support for various serial adapters based on the FTDI -FT8U100AX, FT232BM, FT2232C, FT2232H, FT8U232AM, and FT8U245AM chips. +driver provides support for various serial adapters based on the following +FTDI chips: +.Pp +.Bl -tag -width Ds -offset indent -compact +.It FT8U100AX +.It FT8U232AM +.It FT8U245AM +.It FT232B +.It FT232H +.It FT232R +.It FT245B +.It FT245R +.It FT2232C +.It FT2232D +.It FT2232H +.It FT2232L +.It FT4232H +.It FT200X +.It FT201X +.It FT220X +.It FT221X +.It FT230X +.It FT231X +.It FT234X +.It FT240X +.El .Pp The device is accessed through the .Xr ucom 4
