Re: pppoe(4), add example for ipv6
[What I'm pointing out below looks like a mistake regardless of the
variables in scope.]
On Wed, Oct 22, 2014 at 1:40 AM, Henning Brauer
wrote:
> * Chris Cappuccio [2014-10-22 01:11]:
>> Stuart Henderson [st...@openbsd.org] wrote:
>> > Any comments on the diff in this?
>> >
>> > > +#ifdef INET6
>> > > + sc->sc_sppp.pp_if.if_xflags &= ~IFXF_NOINET6;
>> > > +#endif
>> Aside from what Stefan said, isn't this flag going to be removed
>> in favor of a flag that explicitly enables INET6 for interfaces?
>
> remove yes, no need for a new one.
>
> Index: sbin/ifconfig/ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.287
> diff -u -p -r1.287 ifconfig.c
> --- sbin/ifconfig/ifconfig.c12 Jul 2014 19:58:17 - 1.287
> +++ sbin/ifconfig/ifconfig.c3 Oct 2014 12:58:22 -
> @@ -148,6 +148,7 @@ voidsetiflladdr(const char *, int);
[...]
> void
> +addaf(const char *vname, int value)
> +{
^ *v*name
> + struct if_afreq ifar;
> +
> + strlcpy(ifar.ifar_name, name, sizeof(ifar.ifar_name));
^ name
> + ifar.ifar_af = value;
> + if (ioctl(s, SIOCIFAFATTACH, (caddr_t)&ifar) < 0)
> + warn("SIOCIFAFATTACH");
> +}
> +
> +void
> removeaf(const char *vname, int value)
> {
^ *v*name
> - switch (value) {
> -#ifdef INET6
> - case AF_INET6:
> - setifxflags(vname, IFXF_NOINET6);
> - setifxflags(vname, -IFXF_AUTOCONF6);
> - break;
> -#endif
> - default:
> - errx(1, "removeaf not implemented for this AF");
> - }
> + struct if_afreq ifar;
> +
> + strlcpy(ifar.ifar_name, name, sizeof(ifar.ifar_name));
^ name
> + ifar.ifar_af = value;
> + if (ioctl(s, SIOCIFAFDETACH, (caddr_t)&ifar) < 0)
> + warn("SIOCIFAFDETACH");
> }
Re: malloc in libssl/src/apps
On Sun, May 4, 2014 at 5:00 PM, Alexander Hall wrote:
> On 05/04/14 21:50, Jean-Philippe Ouellet wrote:
>>
>> On Sun, May 04, 2014 at 12:17:16PM -0600, Theo de Raadt wrote:
>>>
>>> We are going to completely ignore diffs which change multiple idioms
>>> at once.
>>
>>
>> Okay.
>>
>>> That is how mistakes get made.
>>
>>
>> Yep, more true than I realized.
>>
>>
>> Here's a simpler one:
>>
>> Index: apps.c
>> ===
>> RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
>> retrieving revision 1.45
>> diff -u -p -r1.45 apps.c
>> --- apps.c 3 May 2014 16:03:54 - 1.45
>> +++ apps.c 4 May 2014 19:35:59 -
>> @@ -209,13 +209,10 @@ chopup_args(ARGS * arg, char *buf, int *
>> *argc = 0;
>> *argv = NULL;
>>
>> - i = 0;
>> if (arg->count == 0) {
>> arg->count = 20;
>> - arg->data = (char **)malloc(sizeof(char *) * arg->count);
>> + arg->data = calloc(arg->count, sizeof(char *));
>> }
>> - for (i = 0; i < arg->count; i++)
>> - arg->data[i] = NULL;
>
>
> General question; Given that NULL theoretically could be != 0, and that we
> generally compare e.g. the malloc() result to NULL specifically, is this
> approach acceptable?
The comparisons `NULL == 0` and `malloc() == 0` are *value* comparison.
After the statement `void **p = calloc(1, sizeof(void **));`, the
comparisons `p == NULL` and therefore `p == 0`, which are *identical*,
are not necessarily true.
Yes, to be correct you can't assume the representation is a string of
NULs, but the rest of your post is misleading.
>
> /Alexander
>
Re: rs, jot: missing headers
On Fri, Apr 11, 2014 at 10:27 PM, Ralph Siegler wrote: > On Fri, 11 Apr 2014 19:27:03 -0430, Andres Perera wrote: > >> On Fri, Apr 11, 2014 at 7:02 PM, Ralph Siegler >> wrote: >>> On Thu, 10 Apr 2014 21:55:13 -0700, Philip Guenther wrote: >>> >>>> On Thu, Apr 10, 2014 at 7:14 PM, Ralph Siegler >>>> wrote: >>>>> On Thu, 14 Nov 2013 23:17:24 -0500, Eitan Adler wrote: >>>>>> I was looking through some OpenBSD code and noticed that rs and jot >>>>>> are both missing #include even though they use getopt. >>>>>> It seems that stdlib.h defines getopt on OpenBSD. However, this is >>>>>> not the correct header file, and it makes it not possible to compile >>>>>> OpenBSD's utilities on other platforms. >>>>> >>>>> I just looked on my linux box and found this in stdlib.h >>>> ... >>>>> So I'm wondering about your assertion that this is "not the correct >>>>> header file"looking at links in your post, do you really mean >>>>> "FreeBSD doesn't define them there but everyone else on the planet >>>>> might"? >>>> >>>> He's perhaps referring to the POSIX standard, which specifies that >>>> that *in a conforming compilation environment* MUST declare >>>> getopt() and MUST NOT declare getopt(). >>>> >>>> (Ya'll know that the current POSIX standard can be downloaded after a >>>> free registration, don'cha?) >>>> >>>> >>>> Philip Guenther >>> >>> Well Philip, had we mentioned any POSIX 2008.1 certified or compliant >>> OS in this thread that would be an interesting point to bring up. But >>> neither GNU/Linux, OpenBSD, nor FreeBSD is fully compliant. >>> >>> On the other hand, Mac OSX Mavericks is 100% compliant and certified, >>> and per spec has, for example, sem_init and sem_destroy in the header >>> files...but lo and behold doesn't actually implement them in the >>> libraries. This and similar show-without-go has bummed out more than >>> one code porter. >>> >>> Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind >>> quarters but will compile and run code having those >>> functions..which is better? >> >> Yes, de facto standards can be important. >> >> Now, does this issue in particular--namely, the decision of which header >> declares getopt()--merit reconsideration? Should OpenBSD or another OS >> depart from POSIX in this regard? If so, what is the motivation? >> >> > > > OpenBSD uses the magic of #ifndef to get away with defining it in two > places, so following POSIX (and the OpenBSD man page) and #include > gets the getopt(3) and so Eitan should be happy. > > But back in the pre-1992 POSIX.2 days, it was defined (as least in some > Unix I know) to be in stdlib.h. And lo and behold OpenBSD will define > it there if it hasn't been defined yet. Well, starting with r1.54 [0], stdlib.h never declares getopt(). However, I think the conversation could continue in spite of that. I would expect "motivation" to be aggregated cost in the form: * a significant amount of patched ports; * a significant amount of affected port prospects; or * a significant amount of patched user programs. You happen to mention the last item. Are there other users interested in this facet of source compatibility? Also, are there other possible costs? [0] http://www.openbsd.org/cgi-bin/cvsweb/src/include/stdlib.h.diff?r1=1.53;r2=1.54;f=h
Re: rs, jot: missing headers
On Fri, Apr 11, 2014 at 7:02 PM, Ralph Siegler wrote: > On Thu, 10 Apr 2014 21:55:13 -0700, Philip Guenther wrote: > >> On Thu, Apr 10, 2014 at 7:14 PM, Ralph Siegler >> wrote: >>> On Thu, 14 Nov 2013 23:17:24 -0500, Eitan Adler wrote: I was looking through some OpenBSD code and noticed that rs and jot are both missing #include even though they use getopt. It seems that stdlib.h defines getopt on OpenBSD. However, this is not the correct header file, and it makes it not possible to compile OpenBSD's utilities on other platforms. >>> >>> I just looked on my linux box and found this in stdlib.h >> ... >>> So I'm wondering about your assertion that this is "not the correct >>> header file"looking at links in your post, do you really mean >>> "FreeBSD doesn't define them there but everyone else on the planet >>> might"? >> >> He's perhaps referring to the POSIX standard, which specifies that that >> *in a conforming compilation environment* MUST declare >> getopt() and MUST NOT declare getopt(). >> >> (Ya'll know that the current POSIX standard can be downloaded after a >> free registration, don'cha?) >> >> >> Philip Guenther > > Well Philip, had we mentioned any POSIX 2008.1 certified or compliant OS > in this thread that would be an interesting point to bring up. But > neither GNU/Linux, OpenBSD, nor FreeBSD is fully compliant. > > On the other hand, Mac OSX Mavericks is 100% compliant and certified, and > per spec has, for example, sem_init and sem_destroy in the header > files...but lo and behold doesn't actually implement them in the > libraries. This and similar show-without-go has bummed out more than one > code porter. > > Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind > quarters but will compile and run code having those functions..which > is better? Yes, de facto standards can be important. Now, does this issue in particular--namely, the decision of which header declares getopt()--merit reconsideration? Should OpenBSD or another OS depart from POSIX in this regard? If so, what is the motivation? > > > Ralph >
Re: pax / tar exit code on truncated input
On Fri, Apr 4, 2014 at 2:12 PM, Philip Guenther wrote:
> On Fri, Apr 4, 2014 at 11:27 AM, Marco Pfatschbacher wrote:
>> On Thu, Apr 03, 2014 at 05:19:45PM -0600, Theo de Raadt wrote:
>>> Interesting. Can we take bath approaches?
>>
>> I don't see why we should not.
>>
>>> Is there a reason to not expose either error?
>>
>> I thought it might break some legacy stuff regarding
>> tapes and such. But since no one spoke up...
>>
>> OK?
>>
>>> > pax does not exit with an error if the processed
>>> > archive is truncated:
>>> >
>>> > # (cd / && tar zcf - bsd | dd count=128 2>/dev/null | tar tzf -)
>>> > bsd
>>> > gzip: stdin: Input/output error
>>> > tar: End of archive volume 1 reached
>>> > gzip: stdout: Broken pipe
>>> > tar: Failed write to archive volume: 1: Broken pipe
>>> > # echo $?
>>> > 0
>>> >
>>> >
>>> > There's two ways to fix this.
>>> > 1) take the exit code of gzip into account:
>>> >
>>> > Index: ar_io.c
>>> > ===
>>> > RCS file: /cvs/src/bin/pax/ar_io.c,v
>>> > retrieving revision 1.44
>>> > diff -u -p -p -u -r1.44 ar_io.c
>>> > --- ar_io.c 11 Jan 2014 05:36:26 - 1.44
>>> > +++ ar_io.c 28 Mar 2014 14:09:37 -
>>> > @@ -337,8 +337,11 @@ ar_close(void)
>>> > (void)close(arfd);
>>> >
>>> > /* Do not exit before child to ensure data integrity */
>>> > - if (zpid > 0)
>>> > + if (zpid > 0) {
>>> > waitpid(zpid, &status, 0);
>>> > + if (WIFEXITED(status) && WEXITSTATUS(status))
>>> > + exit_val = 1;
>>> > + }
>
> Hmm, should that be
> if (!WIFEXITED(status) || WEXITSTATUS(status))
This is incorrect because a process can conclude its work before
terminating because of a signal.
To demonstrate I can use the OP's pipeline:
for i in $(jot 100); do
{ cd /; tar czf - bsd & p=$!; sleep 0.8; kill $p; } | tar tzf -
echo X
done 2>&1 |
awk '/^X/ {a[FNR - c - 1]++; c = FNR} END {print "complete write "a[1]
print "late signal"a[2]
print "short write"a[4]}'
complete write 8 # concluded work, terminated by signal
late signal34 # concluded work, beat the signal race
short write58 # terminated by signal before concluding work
This is only an example. Like other processes, gzip is subject to the race.
Re: Weird loop in ftp client
On Sun, Nov 24, 2013 at 7:29 PM, sven falempin wrote:
>
>
> On Sun, Nov 24, 2013 at 5:57 PM, Andres Perera wrote:
>>
>>
>>
>>
>> On Sun, Nov 24, 2013 at 12:11 PM, sven falempin
>> wrote:
>>>
>>> On Sat, Nov 23, 2013 at 5:47 PM, Theo de Raadt
>>> wrote:
>>>
>>> > > On 2013/11/23 14:39, sven falempin wrote:
>>> > > > Hello,
>>> > > >
>>> > > > Another point of vue :
>>> > > > Because curl is in base, what does ftp client add to the system ?
>>> > >
>>> > > ftp(1) is not without problems (bad ssl support, semi-broken proxy
>>> > > support, difficult code) but it has one major advantage: the small
>>> > > version used on ramdisks is quite small, something like 80k.
>>> > >
>>> > > cURL is not in base, but even if it was, it looks to be much too
>>> > > big for the ramdisks.
>>> >
>>> > As a note to anyone skilled... take the above issues as a challenge.
>>> > If you can improve those problems in ftp(1), we'd love it. But it
>>> > must remain a fairly small program.
>>> >
>>>
>>> Proposed (incomplete) behavior :
>>>
>>> EBADF => fatal
>>> EFBIG, EIO, EPIPE => warn + quit this file ( but EPIPE => wait for
>>> someone
>>> to open the pipe ? or warn + quit this file )
>>
>>
>> $ cat /dev/zero | cat >/dev/null &
>> [1] 15546 28664
>> $ kill -INT 28664
>> $ jobs
>> [1] + Broken pipe cat /dev/zero |
>> Interruptcat > /dev/null
>>
>> here, 15546 exits because of EPIPE during write
>>
>> it does not warn about anything
>>
>> 28664 could've been signaled in any fashion, INT is used to highlight it
>> might be interactive use
>>
>> why should a user interrupt end up as a warning? big friggen deal just
>> exit the program
>
>
> because the job is unfinished, moreover you just kill one of two programs
>
> I do not think your case is relevant.
the process getting EPIPE doesn't know that the process reading was killed
it doesn't know anything other than EPIPE
why woud it spin infinately waiting for the fd to open again, as you
suggested? or even print a warning?
>
>>
>>
>>>
>>> ENOSPC, EDQUOT => warn + quit this file, or warn + sleep (hope someone
>>> rm
>>> some stuff)
>>> EINTR => info + retry ? how many retry ? or for how long ?
>>> EFAULT => call the martian + fatal
>>>
>>>
>>> EAGAIN => call poll and retry ? some fs can do that right ?
>>>
>>> Network related => ignore (fout is not a socket)
>>> But this one
>>> <<
>>> [EIO] The process is a member of a background process
>>> attempting to write to its controlling terminal,
>>> TOSTOP is set on the terminal, the process isn't
>>> ignoring the SIGTTOUT signal and the thread isn't
>>> blocking the SIGTTOUT signal, and either the
>>> process
>>> was created with
>>>
>>> vfork(2)<http://www.openbsd.org/cgi-bin/man.cgi?query=vfork&sektion=2&arch=i386&apropos=0&manpath=OpenBSD+Current>and
>>>
>>> hasn't successfully
>>> executed one of the exec functions or the process
>>> group is orphaned.
>>>
>>> >>
>>> Yes this one would require skillz
>>> of fatal("I dont get it, can you please use your ftp client like anyone
>>> else :-)");
>>>
>>>
>>> --
>>>
>>> -
>>> () ascii ribbon campaign - against html e-mail
>>> /\
>>
>>
>
>
>
> --
> -
> () ascii ribbon campaign - against html e-mail
> /\
Re: Weird loop in ftp client
On Sun, Nov 24, 2013 at 12:11 PM, sven falempin wrote:
> On Sat, Nov 23, 2013 at 5:47 PM, Theo de Raadt >wrote:
>
> > > On 2013/11/23 14:39, sven falempin wrote:
> > > > Hello,
> > > >
> > > > Another point of vue :
> > > > Because curl is in base, what does ftp client add to the system ?
> > >
> > > ftp(1) is not without problems (bad ssl support, semi-broken proxy
> > > support, difficult code) but it has one major advantage: the small
> > > version used on ramdisks is quite small, something like 80k.
> > >
> > > cURL is not in base, but even if it was, it looks to be much too
> > > big for the ramdisks.
> >
> > As a note to anyone skilled... take the above issues as a challenge.
> > If you can improve those problems in ftp(1), we'd love it. But it
> > must remain a fairly small program.
> >
>
> Proposed (incomplete) behavior :
>
> EBADF => fatal
> EFBIG, EIO, EPIPE => warn + quit this file ( but EPIPE => wait for someone
> to open the pipe ? or warn + quit this file )
>
$ cat /dev/zero | cat >/dev/null &
[1] 15546 28664
$ kill -INT 28664
$ jobs
[1] + Broken pipe cat /dev/zero |
Interruptcat > /dev/null
here, 15546 exits because of EPIPE during write
it does not warn about anything
28664 could've been signaled in any fashion, INT is used to highlight it
might be interactive use
why should a user interrupt end up as a warning? big friggen deal just exit
the program
> ENOSPC, EDQUOT => warn + quit this file, or warn + sleep (hope someone rm
> some stuff)
> EINTR => info + retry ? how many retry ? or for how long ?
> EFAULT => call the martian + fatal
>
>
> EAGAIN => call poll and retry ? some fs can do that right ?
>
> Network related => ignore (fout is not a socket)
> But this one
> <<
> [EIO] The process is a member of a background process
> attempting to write to its controlling terminal,
> TOSTOP is set on the terminal, the process isn't
> ignoring the SIGTTOUT signal and the thread isn't
> blocking the SIGTTOUT signal, and either the
> process
> was created with
> vfork(2)<
> http://www.openbsd.org/cgi-bin/man.cgi?query=vfork&sektion=2&arch=i386&apropos=0&manpath=OpenBSD+Current
> >and
> hasn't successfully
> executed one of the exec functions or the process
> group is orphaned.
>
> >>
> Yes this one would require skillz
> of fatal("I dont get it, can you please use your ftp client like anyone
> else :-)");
>
>
> --
>
> -
> () ascii ribbon campaign - against html e-mail
> /\
>
Re: Mention -I option in cvs update synopsis
-l for cvs update is a boolean option that doesn't take an operand On Wed, Aug 21, 2013 at 5:38 PM, Vadim Zhukov wrote: > This adds a mention of "-I name" option for "cvs update" command in > its synopsis. Okay? > > -- > WBR, > Vadim Zhukov > > > Index: man/cvs.1 > === > RCS file: /cvs/src/gnu/usr.bin/cvs/man/cvs.1,v > retrieving revision 1.12 > diff -u -p -r1.12 cvs.1 > --- man/cvs.1 3 Jun 2013 17:02:36 - 1.12 > +++ man/cvs.1 21 Aug 2013 22:06:44 - > @@ -1696,7 +1696,7 @@ executes recursively through subdirector > using the standard \fB\-l\fP option, or specify the recursion > explicitly by using \fB\-R\fP. > .TP > -\fBupdate\fP [\fB\-ACdf\|lPpQqR\fP] [\fB\-d\fP] [\fB\-r\fP > \fItag\fP|\fB\-D\fP \fIdate\fP] \fIfiles\|.\|.\|.\fP > +\fBupdate\fP [\fB\-ACdf\|lPpQqR\fP] [\fB\-d\fP] [\fB\-I\fP \fIname\fP] > [\fB\-r\fP \fItag\fP|\fB\-D\fP \fIdate\fP] \fIfiles\|.\|.\|.\fP > .I Requires: > repository, working directory. > .br >
Re: switch /usr/share/locale to different layout
On Thu, May 30, 2013 at 11:49 PM, Stefan Sperling wrote:
> On Thu, May 30, 2013 at 05:18:48PM -0430, Andres Perera wrote:
>> As I mentioned, there's code that expects the prior layout, and that's
>> confusing.
>>
>> on src/lib/libc/locale/setlocale.c, load_locale_sub() :
>>
>>228 len = snprintf(name, sizeof(name), "%s/%s/%s",
>>229 _PATH_LOCALE, locname, categories[category]);
>>230 if (len < 0 || len >= sizeof(name))
>>231 return -1;
>
> Right, thanks for pointing this out.
>
> I think the above check can just be removed.
> It seems to serve no purpose other than making sure that the path
> constructed from _PATH_LOCALE and the locname argument doesn't
> exceed PATH_MAX. This is redundant because the same check is
> performed again within _xpg4_setrunelocale(). If we assume that functions
> handling other LC_* categories might use different paths in the future,
> it makes sense to perform this overflow check only inside of the
> LC_*-specific functions, rather than upfront.
Besides being redundant, it's generally better to bail on open() error
instead of checking if the length is less than PATH_MAX in
anticipation.
[Unrelated to your patch, but since we are on the subject of path
checks in setlocale()...]
However, since the routines also use locale data paths as keys for a
dynamically allocated cache of their contents, a single check should
persist. This raises an unrelated issue about the cache index: since
libc doesn't support arbitrary paths for locale files, there's no need
to index the cache by full locale data paths because all of the paths
are anchored at _PATH_LOCALE.
>
>> on src/lib/libc/locale/setrunelocale.c, _xpg4_setrunelocale():
>>
>>184 len = snprintf(path, sizeof(path),
>>185 "%s/%s/LC_CTYPE", _PATH_LOCALE, encoding);
>>186 if (len < 0 || len >= sizeof(path))
>>187 return ENAMETOOLONG;
>
> This section is modified as part of my diff, isn't it?
Sorry, this assertion remains correct after your diff so there was no
need for me to list it.
In any case, it's also redundant and should be zapped to prevent
further confusion. There's yet another (x < PATH_MAX) check--making it
the third one--which is a better candidate to keep due to its coupling
with the cache population logic:
125 int
126 _newrunelocale(const char *path)
127 {
128 struct localetable *lt;
129 FILE *fp;
130 _RuneLocale *rl;
131
132 if (strlen(path) + 1 > sizeof(lt->path))
133 return EINVAL;
>
>> > + /* Assume "." locale name. */
>>
>> There should be some notion of syntax for cc_LL.CTYPE, even if only
>> mentioned in comments.
>>
>> E.g.,
>>
>> ISO 3166-1 for country codes and BCP 47 for language tags.
>>
>> glibc did not do this and directly because of that it's a mess to
>> navigate their structure.
>
> You mean we should specify encoding name syntax in a comment?
> If so, my answer would be that recognized encoding names are
> specified by filenames we use in /usr/share/locale. A comment
> documenting the same would risk becoming obsolete over time.
>
> Updated diff, with the redundant check removed:
[...]
Re: switch /usr/share/locale to different layout
On Thu, May 30, 2013 at 3:35 PM, Stefan Sperling wrote:
> I've received several requests for adding new locale names,
> both on this list, and off-list, from several people.
>
> I've been trying to find a way to keep /usr/share/locale reasonably
> clean while also allowing people to use their preferred locale names.
>
> Currently, the list of supported locale names is represented by the
> list of directories in /usr/share/locale. I don't think we should
> continue to maintain a list of _. names
> because such a list cannot be maintained properly.
>
> Some requests that have been made are non-functional changes.
> E.g. adding a doesn't have a functional effect on OpenBSD.
> Still, some users would like to use names containing
> _, for whatever reason.
>
> There have also been requests for supporting locale names such
> as "C.UTF-8". I'm not sure what the use case is but as a side-effect
> of the proposal below such names would also be possible.
The inclusion of C.UTF-8 and POSIX.UTF-8 to their respective standards
has a greater chance of acceptance than the almost-functionally
equivalent en_US.UTF-8. If I define the first two in terms of
en_US.UTF-8 as implemented in various BSD and glibc, the only
difference is sorting order.
>
> POSIX doesn't specify how files in /usr/share/locale are stored.
> bluhm@ suggested to change the filesystem layout such that encoding
> and language are separated. libc will look up locale definition data at
> specific places depending on which of the LC_* categories is being set.
>
> LC_CTYPE support code needs to look at the character encoding only.
> It only cares about the encoding part of the locale name, which by
> convention is the substring after the last dot in the locale name.
Actually, several assertions regarding file structure take place in
the library routines, which you haven't modified in your patch.
>
> The suggested new layout looks like this:
>
> /usr/share/locale/UTF-8/LC_CTYPE
> /usr/share/locale/CP1251/LC_CTYPE
> /usr/share/locale/ISO8859-1/LC_CTYPE
> /usr/share/locale/ISO8859-15/LC_CTYPE
> /usr/share/locale/ISO8859-2/LC_CTYPE
> /usr/share/locale/ISO8859-7/LC_CTYPE
> /usr/share/locale/ARMSCII-8/LC_CTYPE
> /usr/share/locale/ISO8859-4/LC_CTYPE
> /usr/share/locale/ISO8859-13/LC_CTYPE
> /usr/share/locale/CP866/LC_CTYPE
> /usr/share/locale/KOI8-R/LC_CTYPE
> /usr/share/locale/ISO8859-5/LC_CTYPE
> /usr/share/locale/KOI8-U/LC_CTYPE
>
> All other files and directories currently in /usr/share/locale
> can be removed.
>
> If we later add support for language- or country-specific features
> such as LC_COLLATE we can add directories for every language the
> collation code supports:
>
> /usr/share/locale/en/LC_COLLATE
> /usr/share/locale/es/LC_COLLATE
> /usr/share/locale/de/LC_COLLATE
>
> Or even add country names, if necessary and supported by the
> hypothetical collation code:
> /usr/share/locale/it_IT/LC_COLLATE
> /usr/share/locale/it_CH/LC_COLLATE
I did some research a few months ago on the optimal layout for
collation, transliteration, and date/misc formatting:
Cytrus systems don't seem to peruse CLDR, which covers quite alot, and
indexes certain data by cc_LL because it's not transient between
different countries that feature the same language. Since OpenBSD libc
doesn't cover such localization, and it's extremely unlikely that it
will in the near future, it's safe to say that the first hierarchy is
an ok investment.
>
> Does anyone see problems with this plan?
As I mentioned, there's code that expects the prior layout, and that's
confusing.
on src/lib/libc/locale/setlocale.c, load_locale_sub() :
228 len = snprintf(name, sizeof(name), "%s/%s/%s",
229 _PATH_LOCALE, locname, categories[category]);
230 if (len < 0 || len >= sizeof(name))
231 return -1;
on src/lib/libc/locale/setrunelocale.c, _xpg4_setrunelocale():
184 len = snprintf(path, sizeof(path),
185 "%s/%s/LC_CTYPE", _PATH_LOCALE, encoding);
186 if (len < 0 || len >= sizeof(path))
187 return ENAMETOOLONG;
>
> Index: share/locale/ctype/Makefile
> ===
> RCS file: /cvs/src/share/locale/ctype/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
[...]
> Index: lib/libc/locale/setrunelocale.c
> ===
> RCS file: /cvs/src/lib/libc/locale/setrunelocale.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 setrunelocale.c
> --- lib/libc/locale/setrunelocale.c 30 May 2013 18:35:55 - 1.9
> +++ lib/libc/locale/setrunelocale.c 30 May 2013 19:23:16 -
> @@ -171,17 +171,27 @@ found:
> }
>
> int
> -_xpg4_setrunelocale(const char *encoding)
> +_xpg4_setrunelocale(const char *locname)
> {
> char path[PATH_MAX];
> _RuneLocale *rl;
> int error, len;
> + const char *do
src `make obj` wrongly uses dirs instead of symlinks
When BSDSRCDIR is set through /etc/mk.conf or ${MAKECONF} to something
other than the default of /usr/src, make obj won't use symlinks for
`obj' in the affected directories.
Index: distrib/luna88k/Makefile.inc
===
RCS file: /cvs/src/distrib/luna88k/Makefile.inc,v
retrieving revision 1.1
diff -p -u -r1.1 Makefile.inc
--- distrib/luna88k/Makefile.inc21 Apr 2004 18:40:18 - 1.1
+++ distrib/luna88k/Makefile.inc23 Apr 2013 01:30:56 -
@@ -3,7 +3,3 @@
REV=${OSrev}
LDSTATIC=-static
-
-# Hack needed to find kernel images...
-BSDSRCDIR?=/usr/src
-SRCSYSDIR?=${BSDSRCDIR}/sys
Index: distrib/mvme68k/Makefile.inc
===
RCS file: /cvs/src/distrib/mvme68k/Makefile.inc,v
retrieving revision 1.3
diff -p -u -r1.3 Makefile.inc
--- distrib/mvme68k/Makefile.inc24 Jan 2000 04:50:25 - 1.3
+++ distrib/mvme68k/Makefile.inc23 Apr 2013 01:30:56 -
@@ -3,7 +3,3 @@
REV=${OSrev}
LDSTATIC= -static
-
-# Hack needed to find kernel images...
-BSDSRCDIR?=/usr/src
-SRCSYSDIR?=${BSDSRCDIR}/sys
Index: distrib/mvme88k/Makefile.inc
===
RCS file: /cvs/src/distrib/mvme88k/Makefile.inc,v
retrieving revision 1.2
diff -p -u -r1.2 Makefile.inc
--- distrib/mvme88k/Makefile.inc7 Aug 2003 20:57:03 - 1.2
+++ distrib/mvme88k/Makefile.inc23 Apr 2013 01:30:56 -
@@ -3,7 +3,3 @@
REV=${OSrev}
LDSTATIC=-static
-
-# Hack needed to find kernel images...
-BSDSRCDIR?=/usr/src
-SRCSYSDIR?=${BSDSRCDIR}/sys
Re: [patch] tic man page file path error
i see now that src/lib/libcurses has other defines for tic, i apologize to both
Re: [patch] tic man page file path error
$ ident src/lib/libcurses/tinfo/read_bsd_terminfo.c src/lib/libcurses/tinfo/read_bsd_terminfo.c: $OpenBSD: read_bsd_terminfo.c,v 1.18 2010/01/12 23:22:06 nicm Exp $ $ grep -B2 -nw _PATH_TERMINFO src/lib/libcurses/tinfo/read_bsd_terminfo.c 22-#include 23- 24:#define _PATH_TERMINFO "/usr/share/misc/terminfo" -- 60- 61-/* Finally we check the system terminfo file */ 62:*fname++ = _PATH_TERMINFO;
Re: [patch] change identd options to match advice elsewhere
the current version of src/etc/inetd.conf is 1.61. yours is an old one
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 7:12 AM, Stefan Sperling wrote: > On Fri, Mar 22, 2013 at 06:54:24AM -0430, Andres Perera wrote: >> Instead of perpetuating the idea that the number of locales is a >> precious resource tied to directory entries, the routines could parse >> the user supplied string instead of working with a table of all >> possible permutations of ll_CC.CTYPE. This means simplification for >> the build system, simplification for those reasoning about what the >> structure representing a locale should look like, and it also adds >> features without calling for a cliche, tower of babel discussion. >> >> Every field enclosed in brackets denotes the parameter(s) to the LC_ >> function on the LHS: >> >> LC_COLLATE=[ll]_CC.[CTYPE] >> LC_CTYPE=ll_CC.[CTYPE] >> LC_MONETARY=ll_[CC].CTYPE >> LC_NUMERIC=ll_[CC].CTYPE >> LC_TIME=ll_[CC].CTYPE >> LC_MESSAGES=[ll]_[CC].CTYPE >> >> That means that they can be indices to separate flat tables. > > Where is your patch series that implements this in a backwards-compatible > fashion, in small steps that get us from here to there? > > I like the idea of uncoupling locales names from the /usr filesystem a lot. Well, that's just the incentive I needed! > But if it is just an idea it is not as tangible as the patches that Vladimir > is submitting, so it isn't something I can afford to pay attention to > during the limited amount of time I have for OpenBSD development. > As you've picked up on, I have nothing to show for now... hopefully my changes won't interfere.
Re: LC_CTYPE for spanish speaking countries
Instead of perpetuating the idea that the number of locales is a precious resource tied to directory entries, the routines could parse the user supplied string instead of working with a table of all possible permutations of ll_CC.CTYPE. This means simplification for the build system, simplification for those reasoning about what the structure representing a locale should look like, and it also adds features without calling for a cliche, tower of babel discussion. Every field enclosed in brackets denotes the parameter(s) to the LC_ function on the LHS: LC_COLLATE=[ll]_CC.[CTYPE] LC_CTYPE=ll_CC.[CTYPE] LC_MONETARY=ll_[CC].CTYPE LC_NUMERIC=ll_[CC].CTYPE LC_TIME=ll_[CC].CTYPE LC_MESSAGES=[ll]_[CC].CTYPE That means that they can be indices to separate flat tables. N.B. POSIX says that locales don't need to map to directories, so why try to fit this into an expanded hierarchical structure when it's clearly not made for it?
Re: LC_CTYPE for spanish speaking countries
On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling wrote:
> On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote:
>> +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
>> +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
>
> Sorry, but I don't really see the point of this.
>
> All these names are going to map to the same ctype definitions.
> That just clutters the /usr/share/locale directory. Why can't people
> just use es_ES?
Because that's wrong. es_VE for ctype alone won't make a difference,
but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are
different. And dictionary files (e.g., spellings for common cities)
are also different.
The way you specify locales, ll_CC.CHARTYPE, where ll is language and
CC is country-code, is unfortunate because it makes unnecesary
duplication for fields where it shouldn't make a difference, like
ctype, but that's just the way it is
>
> I don't think locale names are standardized, so there should be nothing
> that forces us to support a certain set of locale names.
>
>> +ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
>> +.for c in ${ES_COUNTRIES}
>> +LOCALES += es_${c}.UTF-8
>> +LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
>> +LOCALES += es_${c}.ISO8859-1
>> +LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
>> +LOCALES += es_${c}.ISO8859-15
>> +LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
>> +.endfor
>>
>> LOCALES += fa_IR.UTF-8
>> LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
>
Re: kern decrement
On Tue, Mar 19, 2013 at 10:47 AM, Ted Unangst wrote:
> Maybe we want, maybe we don't. Here's a check to prevent a counter
> from going negative, which usually means an accounting mistake
> somewhere. On the shortcomiing side, it only catches double
> decrements, not missing decrements, so maybe it's not worthwhile.
> Anyway, it was like five minutes to make, figured I'd show it.
>
> Index: lib/libkern/libkern.h
> ===
> RCS file: /cvs/src/sys/lib/libkern/libkern.h,v
> retrieving revision 1.29
> diff -u -p -r1.29 libkern.h
> --- lib/libkern/libkern.h 26 Apr 2012 01:22:31 - 1.29
> +++ lib/libkern/libkern.h 19 Mar 2013 15:10:41 -
> @@ -116,14 +116,11 @@ abs(int j)
>
> #ifndef DIAGNOSTIC
> #defineKASSERT(e) ((void)0)
> +#define DECREMENT(x) x--
why not (x)--?
> #else
> -#ifdef __STDC__
> #defineKASSERT(e) ((e) ? (void)0 :
> \
> __assert("diagnostic ", __FILE__, __LINE__, #e))
> -#else
> -#defineKASSERT(e) ((e) ? (void)0 :
> \
> - __assert("diagnostic ", __FILE__, __LINE__, "e"))
> -#endif
> +#define DECREMENT(x) decrement_checked((x)--, __FILE__, __LINE__, #x)
why (x)-- instead of x-- as before?
> #endif
>
> #ifndef DEBUG
> @@ -141,6 +138,7 @@ abs(int j)
> /* Prototypes for non-quad routines. */
> void__assert(const char *, const char *, int, const char *)
> __attribute__ ((__noreturn__));
> +int64_t decrement_checked(int64_t, const char *, int, const char *);
why not intmax_t instead of int64_t?
> int bcmp(const void *, const void *, size_t);
> voidbzero(void *, size_t);
> voidexplicit_bzero(void *, size_t);
> Index: kern/subr_prf.c
> ===
> RCS file: /cvs/src/sys/kern/subr_prf.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 subr_prf.c
> --- kern/subr_prf.c 3 Apr 2011 16:46:19 - 1.76
> +++ kern/subr_prf.c 19 Mar 2013 15:13:27 -
> @@ -161,6 +161,14 @@ __assert(const char *t, const char *f, i
> t, e, f, l);
> }
>
> +int64_t
> +decrement_checked(int64_t x, const char *f, int l, const char *e)
> +{
> + if (x <= 0)
> + __assert("decrement ", f, l, e);
> + return x;
> +}
> +
> /*
> * tablefull: warn that a system table is full
> */
> Index: kern/vfs_bio.c
> ===
> RCS file: /cvs/src/sys/kern/vfs_bio.c,v
> retrieving revision 1.146
> diff -u -p -r1.146 vfs_bio.c
> --- kern/vfs_bio.c 17 Feb 2013 17:39:29 - 1.146
> +++ kern/vfs_bio.c 19 Mar 2013 15:12:12 -
> @@ -129,7 +129,7 @@ bremfree(struct buf *bp)
> bcstats.numcleanpages -= atop(bp->b_bufsize);
> } else {
> bcstats.numdirtypages -= atop(bp->b_bufsize);
> - bcstats.delwribufs--;
> + DECREMENT(bcstats.delwribufs);
> }
> TAILQ_REMOVE(dp, bp, b_freelist);
> }
> @@ -155,7 +155,7 @@ buf_put(struct buf *bp)
> #endif
>
> LIST_REMOVE(bp, b_list);
> - bcstats.numbufs--;
> + DECREMENT(bcstats.numbufs);
>
> if (buf_dealloc_mem(bp) != 0)
> return;
> @@ -1221,9 +1221,9 @@ biodone(struct buf *bp)
> if (bcstats.numbufs &&
> (!(ISSET(bp->b_flags, B_RAW) || ISSET(bp->b_flags, B_PHYS {
> if (!ISSET(bp->b_flags, B_READ))
> - bcstats.pendingwrites--;
> + DECREMENT(bcstats.pendingwrites);
> else
> - bcstats.pendingreads--;
> + DECREMENT(bcstats.pendingreads);
> }
> if (ISSET(bp->b_flags, B_CALL)) { /* if necessary, call out */
> CLR(bp->b_flags, B_CALL); /* but note callout done */
>
sudo documentation purports wrong loginclass functionality
There are at least two instances in sudo documentation that lead to believe that `use_loginclass' and `sudo -c` behave differently than they do in the implementation WRT which of the target and calling users' loginclass gets applied. sudoers(5): 831 832 use_loginclassIf set, sudo will apply the defaults specified for the 833 target user's login class if one exists. Only 834 available if sudo is configured with the 835 --with-logincap option. This flag is off by default. 836 By "target user" I understand NAME in `sudo -uNAME CMD` or root in absence of `-u'. sudo(8): 69 70 -c classThe -c (class) option causes sudo to run the specified 71 command with resources limited by the specified login class. 72 The class argument can be either a class name as defined in 73 /etc/login.conf, or a single `-' character. Specifying a 74 class of - indicates that the command should be run 75 restricted by the default login capabilities for the user the 76 command is run as. If the class argument specifies an 77 existing user class, the command must be run as root, or the 78 sudo command must be run from a shell that is already root. 79 This option is only available on systems with BSD login 80 classes. 81 In the `sudo -c- CMD` case, I understand that "the user the command is run as" is a synonym of the previous "target user" term; NAME in `sudo -uNAME CMD` or root. In spite both of these, it's the calling user's loginclass that is effective. The patch below attempts to aligns sudo with the documentation. I have no idea if it causes unwarranted privileges to be granted later on in the call stack. Alternatively, the documentation should be fixed to reflect the less useful and counter-intuitive current bevahiour. diff --git a/usr.bin/sudo/sudo.c b/usr.bin/sudo/sudo.c index a299bdc..650c41a 100644 --- a/usr.bin/sudo/sudo.c +++ b/usr.bin/sudo/sudo.c @@ -305,7 +305,7 @@ main(argc, argv, envp) log_error(NO_STDERR|NO_EXIT, "problem with defaults entries"); /* Set login class if applicable. */ -set_loginclass(sudo_user.pw); +set_loginclass(runas_pw); /* Update initial shell now that runas is set. */ if (ISSET(sudo_mode, MODE_LOGIN_SHELL))
Re: ksh bad PS1 ascii octal to char conversion
On Sat, Mar 02, 2013 at 03:08:44PM -0800, Philip Guenther wrote:
> On Sat, 2 Mar 2013, Andres Perera wrote:
> > On Sat, Mar 2, 2013 at 5:13 PM, Philip Guenther
> > wrote:
> ...
> > > Hmm, this is actually changing two things: it's both fixing the problem
> > > that the code is not subtracting '0' from each character before doing the
> > > octal place conversion and it's also changing it to support octal
> > > sequences of fewer than 3 digits. The latter seems unnecessary and isn't
> > > documented, do we really need/want to add it?
> >
> > the behaviour is consistent with bash, which is the shell ksh took it from
> >
> > in addition to that, it's consistent with c string literals and printf(1)
> >
> > ksh having an doing things differently is a bigger bug than
> > precedence... ps1 isn't exactly crucial in scripts
>
> Yet it wasn't important enough to mention or document. Huh. I'm not
> interested without a manpage update to match.
new patch below
like before
* fix the bug with PS1 octal conversion
* add 1 .. 3 octal number feature as seen in bash, printf(1), etc.
aditionally
* document the new behaviour in ksh(1)
* change `c' to int; match other routines
Index: lex.c
===
RCS file: /cvs/src/bin/ksh/lex.c,v
retrieving revision 1.46
diff -p -u -r1.46 lex.c
--- lex.c 20 Jan 2013 14:47:46 - 1.46
+++ lex.c 2 Mar 2013 23:07:19 -
@@ -1349,17 +1349,17 @@ dopprompt(const char *sp, int ntruncate,
case '4':
case '5':
case '6':
- case '7':
- if ((cp[1] > '7' || cp[1] < '0') ||
- (cp[2] > '7' || cp[2] < '0')) {
- snprintf(strbuf, sizeof strbuf,
- "\\%c", *cp);
- break;
- }
- n = cp[0] * 8 * 8 + cp[1] * 8 + cp[2];
- snprintf(strbuf, sizeof strbuf, "%c", n);
- cp += 2;
+ case '7': {
+ int c = 0, i = 3;
+
+ do
+ c = c * 8 + *cp - '0';
+ while (--i && *++cp >= '0' && *cp <= '7');
+ cp -= !!i;
+ strbuf[0] = c;
+ strbuf[1] = '\0';
break;
+ }
case '\\': /* '\' '\' */
strbuf[0] = '\\';
strbuf[1] = '\0';
Index: ksh.1
===
RCS file: /cvs/src/bin/ksh/ksh.1,v
retrieving revision 1.145
diff -p -u -r1.145 ksh.1
--- ksh.1 17 Jan 2013 21:20:25 - 1.145
+++ ksh.1 2 Mar 2013 23:07:21 -
@@ -1662,7 +1662,7 @@ as a special character within double quo
it is safer in this case to escape the backslash
than to try quoting it.
.It Li \e Ns Ar nnn
-The octal character
+The character whose octal value is the 1 to 3 (inclusive) digit number
.Ar nnn .
.It Li \e\e
Insert a single backslash character.
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 12:11 PM, Andres Perera wrote:
> don't know about OP, but yesterday i was surprised when rtlabel had to
> be specified after inet
just double checked; s/after/before
ifconfig(8) section on rtlabel bears no mention about the order
before rearranging, lines were just C sorted:
cat hostname.ral0
inet 192.168.2/24
rtlabel egress
afterboot:
route -vn show -inet | awk '{$2="";print}' | column -t
...
Destination Flags Refs Use MtuPrio Iface Label
default UGS4 557 - 12ral0
10.0.0/24 UC 1 0 - 4 re0
10.0.0.11 UHLc 3 1100 - 4 re0
127/8 UGRS 0 0 33152 8 lo0
127.0.0.1 UH 2 2433152 4 lo0
192.168.2/24 UC 1 0 - 4 ral0
192.168.2.1 UHLc 1 0 - 4 ral0
224/4 URS0 0 33152 8 lo0
>
> i haven't fully researched the relationship between the two, but at
> least during boot's run of netstart, this is a case where order of
> lines and thus ifconfig commands do matter
>
> On Mon, Nov 26, 2012 at 11:56 AM, Jason McIntyre wrote:
>> On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote:
>>> Be more specific about the order of interpretation. Okay?
>>>
>>> diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5
>>> index b07459f..aa8446f 100644
>>> --- share/man/man5/hostname.if.5
>>> +++ share/man/man5/hostname.if.5
>>> @@ -49,6 +49,8 @@ A configuration file is not needed for lo0.
>>> The configuration information is expressed in a line-by-line packed format
>>> which makes the most common cases simpler; those dense formats are
>>> described
>>> below.
>>> +The order of the configuration lines matters, they are interpreted from the
>>> +top down.
>>> Any lines not matching these packed formats are passed directly to
>>> .Xr ifconfig 8 .
>>> The packed formats are converted using a somewhat inflexible parser and
>>>
>>
>> if we say this, then we should provide guidance to folks about how to
>> order the lines. what is the specific problem, or the general rule, that
>> you are addressing?
>>
>> jmc
Re: hostname.if(5) clarification
don't know about OP, but yesterday i was surprised when rtlabel had to be specified after inet i haven't fully researched the relationship between the two, but at least during boot's run of netstart, this is a case where order of lines and thus ifconfig commands do matter On Mon, Nov 26, 2012 at 11:56 AM, Jason McIntyre wrote: > On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: >> Be more specific about the order of interpretation. Okay? >> >> diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 >> index b07459f..aa8446f 100644 >> --- share/man/man5/hostname.if.5 >> +++ share/man/man5/hostname.if.5 >> @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. >> The configuration information is expressed in a line-by-line packed format >> which makes the most common cases simpler; those dense formats are described >> below. >> +The order of the configuration lines matters, they are interpreted from the >> +top down. >> Any lines not matching these packed formats are passed directly to >> .Xr ifconfig 8 . >> The packed formats are converted using a somewhat inflexible parser and >> > > if we say this, then we should provide guidance to folks about how to > order the lines. what is the specific problem, or the general rule, that > you are addressing? > > jmc
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 11:41 PM, Marc Espie wrote: > > On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: > > why would the runtime be attractive for rop? what configuration vm > > needs syscalls that would be attractive to an attacker that can change > > the address of a jump? does the runtime really need to open sockets, > > or spawn processes? (i'm not even talking about languages) > > [...] > > > i'm completely serious. i can use a js vm and write a trivial systrace > > sandbox like ssh's which only allows read() > > You're only talking about one small aspect of security. Just because your > javascript apps cannot interact with your OS doesn't make them secure. that's not a specialized condition reserved to js interpreters, and i also don't wish to talk about larger aspects because i'd be entering an area that's dominated by quality of implementation issues that aren't solved by os access control tools > They also have to be reliable, not trample on each other memory, so that > you get predictable behavior and only have to worry about logic errors in > each app. same applies > People are *relying* on javascript to do real work. If you're > depositing documents on servers. If you're using gmail. If you're using > any kind of web app, basically. that's interesting. the subject is about a potential configuration language that is managed by the administrator, such as polkit's and sudo's > > > Every day, people say that high-level languages like java or js are more > secure. They are missing the point. Just because they don't have buffer > overflows doesn't protect them from sloppy developer errors. Just the > opposite, actually: being stupid is no longer a barrier to writing > "production" code, and you end up with idiots writing code, instead of > being stopped right away by C's nastiness. every time i pair malloc() with free(), i don't feel enlightened; i don't feel like wallowing in thoughts of my own self-worth; i don't feel like masturbating intellectually i should know by now, given that i'm 3 months into rewriting infrastrusture/bin/dpb in C
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 2:53 PM, Kevin Chadwick wrote: > On Thu, 22 Nov 2012 14:18:59 -0430 > Andres Perera wrote: > >> there's still no tie-in to the privileges of the process, > > It still lets a process do something unintended. In fact getting a > browser to execute an external javascript program is a threat in itself > that could have no end of custom instructions executed as a normal user. something unintended like fiddling with its registers and increasing $pc in gdb > In fact getting a browser to execute an external javascript program is a > threat in itself > that could have no end of custom instructions executed as a normal user. i'm convinced that you don't know what javascript is and in spite of that decided that it carries along the dom apis wherever it goes, like some sort of disfunctional sidekick relationship ala robin and batman > >> as explained >> in my previous message, and there's also a new, pending tie-in; "POSIX >> being influenced by such things" -- i doubt that js is creeping its >> merry way into posix. > > Your twisting my meaning and I'm sure we're just boring everyone and > polluting this thread for sure now and this is @tech. > that's just the pussiest way of saying "i've mistakenly sprayed my comments with acronyms like rop and jit, but i have no fucking clue how they relate"
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 1:52 PM, Kevin Chadwick wrote: > On Thu, 22 Nov 2012 13:27:46 -0430 > Andres Perera wrote: > >> but jit isn't irreparably interleaved with js >> > > The latest polkit actually depends on the javascript package. specifically, js185, aka spidermonkey, aka: MOZ_ARG_DISABLE_BOOL(methodjit, [ --disable-methodjit Disable method JIT support], ENABLE_METHODJIT= ) MOZ_ARG_DISABLE_BOOL(tracejit, [ --disable-tracejit Disable tracing JIT support], ENABLE_TRACEJIT=) > >> am i compromising by running luajit in interpreter mode instead of the >> reference implementation, moreover, would that imply that lua the >> language is insecure or is the specific implementation at fault? >> >> why would the runtime be attractive for rop? > > having the javscript package on your system when you otherwise > wouldn't can allow an attacker to use code he is likely familiar with > return to libc style to modify the capability of code marked executable. > This may not generally mean that much but on a small server or embedded > system it may mean a lot. The main point is that this is an example of a > Redhat developer having free reign to do silly things and actually > increased the difficulty of the average human configuring polkit and > without evaluating all potential consequences and scenarios. POSIX being > influenced by such things is wrong. there's still no tie-in to the privileges of the process, as explained in my previous message, and there's also a new, pending tie-in; "POSIX being influenced by such things" -- i doubt that js is creeping its merry way into posix. > > > p.s. When I said polkit is cross-platform, I really meant it's > portable.
Re: upstream vendors and why they can be really harmful
On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick wrote: > On Thu, 22 Nov 2012 09:30:41 -0430 > Andres Perera wrote: > >> i'm not sure how using js for configuration files, as opposed to using >> a language commonly deployed for the same purpose, such as lua, >> presents an innate constraint on security. > > Firstly the article mentioned JIT preventing true randomisation. > > Secondly pulling in JS as a dependency even on servers is rediculous and > is a language very familiar to attackers and unfamiliar to many users. > It would be especially, shall we say kind to attackers utilising rop > attacks. but jit isn't irreparably interleaved with js am i compromising by running luajit in interpreter mode instead of the reference implementation, moreover, would that imply that lua the language is insecure or is the specific implementation at fault? why would the runtime be attractive for rop? what configuration vm needs syscalls that would be attractive to an attacker that can change the address of a jump? does the runtime really need to open sockets, or spawn processes? (i'm not even talking about languages) > > >> >> then i would point out that, if anything, a popular js implementation >> receives broader testing than sudo's dsl. > > And it needs it and turns up bugs every week and grows constantly. Are > you serious! > i'm completely serious. i can use a js vm and write a trivial systrace sandbox like ssh's which only allows read() what now?
Re: upstream vendors and why they can be really harmful
i'm not sure how using js for configuration files, as opposed to using a language commonly deployed for the same purpose, such as lua, presents an innate constraint on security. if i'm somehow expected to ignore how unlikely it is for the configuration vm to: a. intentionally have the ability of boundlessly influencing program behavior, or b. provide exploits that aid users with the privileges required for configuring said program in boundlessly influencing program behaviour, and that said person even has the incentive to do so (maybe in your site sudo configuration files are generated from entries to pub/guestbook.html?) then i would point out that, if anything, a popular js implementation receives broader testing than sudo's dsl. On Thu, Nov 22, 2012 at 9:04 AM, Kevin Chadwick wrote: >> Follow-up interview, much better to say what you want instead of having >> people >> interpret your email. > > Do you know polkit (which I believe is cross platform but I prefer to > remove it, primarily because it gives little indication of what is > allowed and requires constant review, unlike sudo) now uses Javascript > for it's configuration files because the author (from his blog) > believed JS to be the most universal language he could think of. I'm > still unsure if he's serious or just taking the piss. I'm sure though > he writes security software, he didn't realise any security > ramifications in any case. > > Anyway sorry to lower the tone. Cross polination and health is > important. Less can certainly be more and mean more sooner for everyone. > > -- > ___ > > 'Write programs that do one thing and do it well. Write programs to work > together. Write programs to handle text streams, because that is a > universal interface' > > (Doug McIlroy) > ___
Re: ##@!#@# gnu tools
On Thu, Nov 15, 2012 at 1:13 PM, Marc Espie wrote: > On Thu, Nov 15, 2012 at 05:53:52PM +0100, Reyk Floeter wrote: >> For all the GNU people, here is how a Makefile for hello.c should look like: >> PROG= hello >> NOMAN= yes >> .include >> >> Yes, you're supposed to provide a man page hello.1 and remove the NOMAN line >> :) > > Well, a portable Makefile for hello.c would be: > > .POSIX: > > OBJS = hello.o > > hello: $(OBJS) > $(CC) -o $@ $(CFLAGS) $(OBJS) > > > > anything else (all, install, whatever) are just bonus. > Surprisingly, .PHONY is not even standard... > a portable Makefile would be: .POSIX: hello: because posix mandates built-in implicit rules for `.c:' (why is pointing out these examples useful?)
Re: dc(1) exp improvements
On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek wrote:
> Hi,
>
> And here's a diff to repair ^, whcih now produces correct results for
> things like
>
> (dc)0.1 _1 ^p
> or
> (bc)0.1 ^ -1
>
> The diff is against very current, so beware.
i've lightly tested it against gnu bc and it works
i do have 2 small comments below
>
> Please test. I have some regress test updates for dc as well. t9 turns
> out to be a wrong test (computation of 2.1 ^ 500). That is fixed with
> this diff as well.
>
> -Otto
>
> Index: bcode.c
> ===
> RCS file: /cvs/src/usr.bin/dc/bcode.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 bcode.c
> --- bcode.c 6 Nov 2012 16:00:05 - 1.44
> +++ bcode.c 6 Nov 2012 19:42:07 -
> @@ -257,6 +257,12 @@ init_bmachine(bool extended_registers)
> (void)signal(SIGINT, sighandler);
> }
>
> +u_int
> +bmachine_scale(void)
> +{
> + return bmachine.scale;
> +}
> +
> /* Reset the things needed before processing a (new) file */
> void
> reset_bmachine(struct source *src)
> @@ -991,7 +997,7 @@ bsub(void)
> }
>
> void
> -bmul_number(struct number *r, struct number *a, struct number *b)
> +bmul_number(struct number *r, struct number *a, struct number *b, u_int
> scale)
> {
> BN_CTX *ctx;
>
> @@ -1007,7 +1013,7 @@ bmul_number(struct number *r, struct num
>
> if (rscale > bmachine.scale && rscale > ascale && rscale > bscale) {
> r->scale = rscale;
> - normalize(r, max(bmachine.scale, max(ascale, bscale)));
> + normalize(r, max(scale, max(ascale, bscale)));
> } else
> r->scale = rscale;
the function unconditionally sets r->scale to rscale, but the
operation is duplicated across `if' bodies. interpreting a diff for
the function is difficult because the intent is unclear
> }
> @@ -1029,7 +1035,7 @@ bmul(void)
> }
>
> r = new_number();
> - bmul_number(r, a, b);
> + bmul_number(r, a, b, bmachine.scale);
>
> push_number(r);
> free_number(a);
> @@ -1160,7 +1166,7 @@ bexp(void)
> struct number *a, *p;
> struct number *r;
> boolneg;
> - u_int scale;
> + u_int rscale;
>
> p = pop_number();
> if (p == NULL) {
> @@ -1191,7 +1197,7 @@ bexp(void)
> if (BN_is_negative(p->number)) {
> neg = true;
> negate(p);
> - scale = bmachine.scale;
> + rscale = bmachine.scale;
> } else {
> /* Posix bc says min(a.scale * b, max(a.scale, scale) */
> u_long b;
> @@ -1199,30 +1205,35 @@ bexp(void)
>
> b = BN_get_word(p->number);
> m = max(a->scale, bmachine.scale);
> - scale = a->scale * (u_int)b;
> - if (scale > m || (a->scale > 0 && (b == BN_MASK2 ||
> + rscale = a->scale * (u_int)b;
> + if (rscale > m || (a->scale > 0 && (b == BN_MASK2 ||
> b > UINT_MAX)))
> - scale = m;
> + rscale = m;
> }
>
> if (BN_is_zero(p->number)) {
> r = new_number();
> bn_check(BN_one(r->number));
> - normalize(r, scale);
> + normalize(r, rscale);
> } else {
> + u_int scale, ascale = a->scale;
`scale' should be renamed for clarity to signify that it's an
accumulator for `ascale'. at its current state, not being prefixed by
a letter that is, `scale' looks more important than it is
Re: Hibernate support
nice would it be feasible to also compress kernel dumps once the compression logic is in place for hibernation? On Wed, Jul 11, 2012 at 11:41 AM, Mike Larkin wrote: > Hibernate support (suspend-to-disk) will be shortly enabled for i386 + wd > machines. > > Some FAQs, before I commit the change to turn it on: > > 1. If you have anything other than i386 + wd, it won't work. Don't report it. > Other archs + disk types are being worked on now that i386 + wd is working. > This means, *FOR NOW*, it works on combinations like this: > > wd0 at pciide0 channel 0 drive 0: > > .. NOT this: > > ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2 > scsibus0 at ahci0: 32 targets > sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct > > > > 2. Hibernate writes to swap (at the end of your swap). If you have too small > a swap, it won't work, or if there are swap pages in use at the end of your > swap that overlap with what we want. You need at least "size of mem + 64MB" > of swap at the end of swap, free, at the time of hibernate. > > 3. We do *not* do encryption of the hibernated image, even if you have turned > on encrypted swap. > > 4. If you change your memory size/layout or change your kernel, we will detect > this and abort any hibernate resumes. The resume will be a normal boot then. > > 5. It will be very slow for the time being - this is a known problem that > I am working on fixing, but for now, we will wastefully write all memory, > even pages that are not in use. This will be fixed, so please don't report > that "it's slow". On my machine with 1.5GB ram, it takes a few minutes to > write > everything out, and about 30s to read it back in on resume. > > 6. Hibernate can be triggered via 'ZZZ' in -current (capital 'Z's for > hibernate, > lowercase 'z' for suspend). > > 7. Right now, there is no unwind support for errors. This means that just > about every failure case will result in a panic or reboot. This too is being > worked on. > > If you have a supported (see #1) configuration and want to test it, let us > know if it works (or doesn't). There won't be a diff posted here, it will just > get enabled, probably sometime later tonight or tomorrow. > > -ml
Re: tmux and login shells
i agree. also disliked loginShell in xresources, but that's very easy to alter would be nice to hear an explanation from the author(s) of tmux about always perusing a login shell
Re: cwm tiling
tiling is only useful for text applications
for that i use tmux
On Sun, Jun 3, 2012 at 12:37 PM, Alexander Polakov wrote:
> I'd like to start a discussion about adding tiling to cwm with
> these two diffs.
>
> First diff adds a helper function to get the area of the screen.
> I don't have a second screen here, so no idea if it works with
> Xinerama (please test!).
>
> Index: calmwm.h
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.146
> diff -u -r1.146 calmwm.h
> --- calmwm.h 16 May 2012 01:17:14 - 1.146
> +++ calmwm.h 2 Jun 2012 15:16:26 -
> @@ -103,6 +103,13 @@
> int right;
> };
>
> +struct rect {
> + int x;
> + int y;
> + int width;
> + int height;
> +};
> +
> struct winname {
> TAILQ_ENTRY(winname) entry;
> char *name;
> @@ -118,12 +125,7 @@
> XSizeHints *size;
> Colormap cmap;
> u_int bwidth; /* border width */
> - struct {
> - int x; /* x position */
> - int y; /* y position */
> - int width; /* width */
> - int height;/* height */
> - } geom, savegeom;
> + struct rect geom, savegeom;
> struct {
> int basew; /* desired width */
> int baseh; /* desired height */
> @@ -361,6 +363,7 @@
> XineramaScreenInfo *screen_find_xinerama(struct screen_ctx *, int, int);
> struct screen_ctx *screen_fromroot(Window);
> void screen_init_xinerama(struct screen_ctx *);
> +struct rect *screen_get_area(struct screen_ctx *, int);
> void screen_update_geometry(struct screen_ctx *, int,
> int);
> void screen_updatestackingorder(struct screen_ctx *);
>
> Index: client.c
> ===
> RCS file: /cvs/xenocara/app/cwm/client.c,v
> retrieving revision 1.94
> diff -u -r1.94 client.c
> --- client.c 16 May 2012 01:09:17 - 1.94
> +++ client.c 2 Jun 2012 15:16:27 -
> @@ -277,8 +277,7 @@
> client_maximize(struct client_ctx *cc)
> {
> struct screen_ctx *sc = cc->sc;
> - int xmax = sc->xmax, ymax = sc->ymax;
> - int x_org = 0, y_org = 0;
> + struct rect *sa;
>
> if (cc->flags & CLIENT_FREEZE)
> return;
> @@ -300,28 +299,9 @@
> cc->savegeom.x = cc->geom.x;
> }
>
> - if (HasXinerama) {
> - XineramaScreenInfo *xine;
> - /*
> - * pick screen that the middle of the window is on.
> - * that's probably more fair than if just the origin of
> - * a window is poking over a boundary
> - */
> - xine = screen_find_xinerama(sc,
> - cc->geom.x + cc->geom.width / 2,
> - cc->geom.y + cc->geom.height / 2);
> - if (xine == NULL)
> - goto calc;
> - x_org = xine->x_org;
> - y_org = xine->y_org;
> - xmax = xine->width;
> - ymax = xine->height;
> - }
> -calc:
> - cc->geom.x = x_org + sc->gap.left;
> - cc->geom.y = y_org + sc->gap.top;
> - cc->geom.height = ymax - (sc->gap.top + sc->gap.bottom);
> - cc->geom.width = xmax - (sc->gap.left + sc->gap.right);
> + sa = screen_get_area(sc, 1);
> + memcpy(&cc->geom, sa, sizeof(*sa));
> + free(sa);
> cc->bwidth = 0;
> cc->flags |= CLIENT_MAXIMIZED;
>
> @@ -333,7 +313,7 @@
> client_vertmaximize(struct client_ctx *cc)
> {
> struct screen_ctx *sc = cc->sc;
> - int y_org = 0, ymax = sc->ymax;
> + struct rect *sa;
>
> if (cc->flags & CLIENT_FREEZE)
> return;
> @@ -357,21 +337,11 @@
> cc->bwidth = 0;
> }
>
> - if (HasXinerama) {
> - XineramaScreenInfo *xine;
> - xine = screen_find_xinerama(sc,
> - cc->geom.x + cc->geom.width / 2,
> - cc->geom.y + cc->geom.height / 2);
> - if (xine == NULL)
> - goto calc;
> - y_org = xine->y_org;
> - ymax = xine->height;
> - }
> -calc:
> - cc->geom.y = y_org + sc->gap.top;
> - cc->geom.height = ymax - (cc->bwidth * 2) - (sc->gap.top +
> - sc->gap.bottom);
> + sa = screen_get_area(sc, 1);
> + cc->geom.y = sa->y;
> + cc->geom.height = sa->height - (cc->bwidth * 2);
> cc->flags |= CLIENT_VMAXIMIZED;
> + free(sa);
>
> resi
Re: -not for find(1)
On Mon, Feb 27, 2012 at 3:36 PM, Landry Breuil wrote: > On Mon, Feb 27, 2012 at 03:24:05PM -0430, Andres Perera wrote: >> linux does >> >> worth pointing out that some tests in old firefox ports (maybe still >> there) failed because the lack of -not > > Are you thinking about > https://bugzilla.mozilla.org/show_bug.cgi?id=665040 ? yes well, don't let my talk of 8 month old resolved bug reports persuade you "-not" stands on its own merits. > Anyway, i think that was the only occurence of -not, since > grep -r -- ' \-not' B * in mozilla-central yields nothing. > > Landry > >> On Mon, Feb 27, 2012 at 3:01 PM, Ted Unangst wrote: >> > On Mon, Feb 27, 2012, Steffen Daode Nurpmeso wrote: >> >> this patch adds the -not operator to find(1). >> >> I personally always found -not easier to use due to shell >> >> escaping, but today may laziness has bitten back. >> >> And "it's just one more non-POSIX-compliant option". >> > >> > This makes a lot of sense to me, but it's good to research what other >> > systems support the same option. B Linux, FreeBSD, and Solaris are >> > worthy references.
Re: -not for find(1)
linux does worth pointing out that some tests in old firefox ports (maybe still there) failed because the lack of -not On Mon, Feb 27, 2012 at 3:01 PM, Ted Unangst wrote: > On Mon, Feb 27, 2012, Steffen Daode Nurpmeso wrote: >> this patch adds the -not operator to find(1). >> I personally always found -not easier to use due to shell >> escaping, but today may laziness has bitten back. >> And "it's just one more non-POSIX-compliant option". > > This makes a lot of sense to me, but it's good to research what other > systems support the same option. B Linux, FreeBSD, and Solaris are > worthy references.
Re: etc/rc.d/spamlogd needs pflog
On Sat, Aug 6, 2011 at 7:11 AM, Stuart Henderson wrote:
> Since pflog interface creation was moved to rc.d/pflogd, you can
> no longer run spamlogd without also running pflogd. This diff copies
> the interface creation code from pflogd (it doesn't hurt to create
> pflog0 twice).
>
> This doesn't handle the case with spamlogd -l where a non-default
> interface is used (but neither does pflogd handle the case with -i),
> but I think for non-default options it's reasonable to expect the
> user to do a little more work (e.g. 'echo up > /etc/hostname.pflog1').
>
> Index: spamlogd
> ===
> RCS file: /cvs/src/etc/rc.d/spamlogd,v
> retrieving revision 1.1
> diff -u -p -r1.1 spamlogd
> --- spamlogd B B 8 Jul 2011 02:15:34 - B B B 1.1
> +++ spamlogd B B 6 Aug 2011 11:32:39 -
> @@ -10,6 +10,17 @@ rc_reload=NO
>
> B rc_pre() {
> B B B B [ B X"${spamd_flags}" != X"NO" -a X"${spamd_black}" = X"NO" ]
this check needs to return 1 if it fails
or you're assuming it's a set -e shell?
> +
> + B B B if pfctl -si | grep -q Enabled; then
> + B B B B B B B ifconfig pflog0 create
> + B B B B B B B if ifconfig pflog0; then
> + B B B B B B B B B B B ifconfig pflog0 up
> + B B B B B B B else
> + B B B B B B B B B B B return 1
> + B B B B B B B fi
> + B B B else
> + B B B B B B B return 1
> + B B B fi
> B }
>
> B rc_cmd $1
Re: fdisk geom fixes
On Mon, Jul 4, 2011 at 11:32 PM, Kenneth R Westerback
wrote:
> On Mon, Jul 04, 2011 at 09:38:37PM -0430, Andres Perera wrote:
>> On Mon, Jul 4, 2011 at 8:56 PM, Kenneth R Westerback
>> wrote:
>> > The use of CHS should be hard and attempted only by
>> > those who know all the rules already.
>>
>> which is made difficult by not being able to select a subset of cyls,
>> since fdisk caps them at 1024 on amd64
>>
>> note that geom was, and continues to be, only relevant for the
>> duration of that fdisk instance
>>
>> all the changes are just to help with partitioning, e.g. by using a
>> percentage based on the subset of cyls that i could select, or just
>> globbing the entire cyl range
>>
>> at the moment it is not for people that know the intricacies, as
>> you're implying. it doesn't allow for anything useful
>>
>> if geom is removed from fdisk, then the obsd install ideally has to
>> account for geom changes before making mbr partitions
>
> MBR partitions are created based solely on lba info, with the chs
> info just faked in. Removing geom would have no impact on the install
> as far as I know. At least for 99.9% of situations. That would be
> an interesting experiment.
>
> Ken
even though it's ultimately the same for people that don't change
them, mbr partitions are not created from lba in fdisk.
the data goes through this mangling:
1. lba (disklabel, which means that it's not necessarily lba)
2. boundless CHS
3. boundless CHS is influenced by geom ("disk" command)
4. 255/63 check (cylinders are ignored for the check and always written as 1024)
5. partitions are created based on boundless CHS, partition end is
usually aligned with last cylinder
6. dishonest bounded CHS gets written to mbr
from this point, it either writes 255 in all CHS fields except the 2
bit S field, or an almost honest representation of lba
since you can change the "boundless CHS" through geom, then CHS values
do influence, just not the ones in the MBR... it's important to make
that distinction in order to get anywhere with this mess
besides that,
for people that want to partition mbr after *really* changing CHS
values: during install they have to access the shell and change CHS
with disklabel before fdisk. that's fine since it is an unusual need:
disklabel (fill in boundstart and end, or don't partition yet) ->
fdisk -> disklabel
but two things need to be clarified: the order is assbackwards.
disklabel influences fdisk, and fdisk influences disklabel (to set
boundstart and boundend). this complexity is a problem no matter what
happens to geom with fdisk
the second thing is that the "disk" command is misleading since it
does not expose the relationship between disklabel and fdisk, in fact,
it actively confuses how the two relate. improving the "disk" command,
like i suggested + writing to disklabel, would lead to less circling
dependencies. but the better solution requires more drastic changes
than the ones i proposed: disklabel should not handle geom +
partitions, it's a mess. whatever handles geom comes before fdisk and
disklabel
Re: fdisk geom fixes
On Mon, Jul 4, 2011 at 8:56 PM, Kenneth R Westerback
wrote:
> The use of CHS should be hard and attempted only by
> those who know all the rules already.
which is made difficult by not being able to select a subset of cyls,
since fdisk caps them at 1024 on amd64
note that geom was, and continues to be, only relevant for the
duration of that fdisk instance
all the changes are just to help with partitioning, e.g. by using a
percentage based on the subset of cyls that i could select, or just
globbing the entire cyl range
at the moment it is not for people that know the intricacies, as
you're implying. it doesn't allow for anything useful
if geom is removed from fdisk, then the obsd install ideally has to
account for geom changes before making mbr partitions
>
>>
>> >
>> >>
>> >> part.c:
>> >>
>> >> x86* maxhead should be 254, not 255 (other arches?)
>> >
>> > But 6 lines ago you say maxhead should be 255 not 256? Perhaps you can
>> > provide the valid ranges for all of these and your references for
>> > the claim. An example on how you manage to cause yourself a problem
>> > would also be helpful.
>>
>> these are different maxheads. one is the maximum numbers and this is
>> the INDEXED maximum number, ie its 0 based. you should read the code
>> because the two functions are checking for different things; the
>> relationship between the offsets was the same as now. e.g., one checks
>> for cyl > 1024 and this function cyl > 1023. please read the original
>> before the patch
>
> I spent some time reviewing the code. I was asking only for a clear
> statement of your analysis.
>
>>
>> my reference is a bug in certain versions of msdos that don't allow
>> head > 254 (INDEXED) or 255 (TOTAL)
>
> This is not a reference. This is just restating your opinion. A reference
> would be a link, a cut and paste of a manual, etc.
http://www.cs.cmu.edu/~ralf/files.html
Interrupt List, Part B (364k)
B-1302---
INT 13 - DISK - READ SECTOR(S) INTO MEMORY
"All versions of MS-DOS (including MS-DOS 7 [Windows 95]) have a bug
which prevents booting on hard disks with 256 heads (FFh), so many
modern BIOSes provide mappings with at most 255 (FEh) heads some
cache drivers flush their buffers when detecting that DOS is bypassed
by directly issuing INT 13h from applications. A dummy read can
be used as one of several methods to force cache flushing for unknown
caches (e.g. before rebooting)."
>
>>
>> also, most oses, obsd included, generate their equivalent of fake
>> disklabel with sectors fixed at 63, heads at 255, and variable length
>> cyls
>
> This is true. How is it relevant to the actual limits that those
> fiddling with the complexitites of CHS should have available?
>
>>
>> why allow heads to go to 256?
>
> Why not? OpenBSD is not MSDOS, certain version of which you think
> have a bug.
that collides with the inclusion of a fat32-esque pbr included in
biosboot. there's clearly an interest in maintaining compatibility
>
>>
>> >
>> >>
>> >> maxcyl gets set to 1023 before this function gets called, so it's a
>> >> redundant check
>> >>
>> >> Index: src/sbin/fdisk/cmd.c
>> >> ===
>> >> RCS file: /cvs/src/sbin/fdisk/cmd.c,v
>> >> retrieving revision 1.45
>> >> diff -p -u -r1.45 cmd.c
>> >> --- src/sbin/fdisk/cmd.c ?? ?? ??2 Jul 2010 02:54:09 - ?? ?? ?? 1.45
>> >> +++ src/sbin/fdisk/cmd.c ?? ?? ??4 Jul 2011 20:55:22 -
>> >> @@ -67,9 +67,10 @@ Xreinit(cmd_t *cmd, disk_t *disk, mbr_t
>> >> ??int
>> >> ??Xdisk(cmd_t *cmd, disk_t *disk, mbr_t *mbr, mbr_t *tt, int offset)
>> >> ??{
>> >> - ?? ?? int maxcyl ??= 1024;
>> >> - ?? ?? int maxhead = 256;
>> >> - ?? ?? int maxsec ??= 63;
>> >> + ?? ?? u_int32_t maxcyl ??= 1024;
>> >> + ?? ?? u_int32_t maxhead = 255;
>> >> + ?? ?? u_int32_t maxsec ??= 63;
>> >> + ?? ?? u_int32_t dmaxcyl = 0;
>> >
>> > What's the point of u_int32_t?
>>
>> if you look at the definition of struct defining disk->label's type, you'd
>> know
>
> If you read the definition of ask_num() you'd know why I asked.
this is a legitimate problem :). on amd64 an int is 32 bits, so i
hadn't noticed. will fix
>
>>
>> that applies to dmaxcyl only, changed others for consistency
>>
>> >
>> >>
>> >> ?? ?? ?? /* Print out disk info */
>> >> ?? ?? ?? DISK_printmetrics(disk, cmd->args);
>> >> @@ -80,8 +81,15 @@ Xdisk(cmd_t *cmd, disk_t *disk, mbr_t *m
>> >> ?? ?? ?? maxsec ??= 999;
>> >> ??#endif
>> >>
>> >> + ?? ?? if (disk->label)
>> >> + ?? ?? ?? ?? ?? ?? dmaxcyl = disk->label->cylinders;
>> >> +
>> >> ?? ?? ?? /* Ask for new info */
>> >> ?? ?? ?? if (ask_yn("Change disk geometry?")) {
>> >> + ?? ?? ?? ?? ?? ?? if (dmaxcyl > maxcyl) {
>> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? printf("Warning setting cyl beyond %u
>> >> forces LBA\n", maxcyl);
>> >> + ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? maxcyl = dmaxcyl;
>> >> + ?? ?? ?? ?? ?? ?? }
>> >>
>> >
>> > Since ask_num won't permit numbers > max, how will LBA be forced?
>>
>>
Re: fdisk geom fixes
On Mon, Jul 4, 2011 at 7:31 PM, Kenneth R Westerback
wrote:
> On Mon, Jul 04, 2011 at 02:26:42PM -0700, andre...@zoho.com wrote:
>> cmd.c:
>>
>> x86* maxhead should be 255, not 256
>>
>> make geom less useless by using disklabel for cyl, if available
>
> geom is useless, period. Making it easier will only encourage people
> to use it.
given that fdisk becomes before disklabel in install.md, the geom will
be set, and mbr partitions made based on it, before disklabel is
invoked
>
>>
>> part.c:
>>
>> x86* maxhead should be 254, not 255 (other arches?)
>
> But 6 lines ago you say maxhead should be 255 not 256? Perhaps you can
> provide the valid ranges for all of these and your references for
> the claim. An example on how you manage to cause yourself a problem
> would also be helpful.
these are different maxheads. one is the maximum numbers and this is
the INDEXED maximum number, ie its 0 based. you should read the code
because the two functions are checking for different things; the
relationship between the offsets was the same as now. e.g., one checks
for cyl > 1024 and this function cyl > 1023. please read the original
before the patch
my reference is a bug in certain versions of msdos that don't allow
head > 254 (INDEXED) or 255 (TOTAL)
also, most oses, obsd included, generate their equivalent of fake
disklabel with sectors fixed at 63, heads at 255, and variable length
cyls
why allow heads to go to 256?
>
>>
>> maxcyl gets set to 1023 before this function gets called, so it's a
>> redundant check
>>
>> Index: src/sbin/fdisk/cmd.c
>> ===
>> RCS file: /cvs/src/sbin/fdisk/cmd.c,v
>> retrieving revision 1.45
>> diff -p -u -r1.45 cmd.c
>> --- src/sbin/fdisk/cmd.c B B B 2 Jul 2010 02:54:09 - B B B 1.45
>> +++ src/sbin/fdisk/cmd.c B B B 4 Jul 2011 20:55:22 -
>> @@ -67,9 +67,10 @@ Xreinit(cmd_t *cmd, disk_t *disk, mbr_t
>> B int
>> B Xdisk(cmd_t *cmd, disk_t *disk, mbr_t *mbr, mbr_t *tt, int offset)
>> B {
>> - B B int maxcyl B = 1024;
>> - B B int maxhead = 256;
>> - B B int maxsec B = 63;
>> + B B u_int32_t maxcyl B = 1024;
>> + B B u_int32_t maxhead = 255;
>> + B B u_int32_t maxsec B = 63;
>> + B B u_int32_t dmaxcyl = 0;
>
> What's the point of u_int32_t?
if you look at the definition of struct defining disk->label's type, you'd
know
that applies to dmaxcyl only, changed others for consistency
>
>>
>> B B B /* Print out disk info */
>> B B B DISK_printmetrics(disk, cmd->args);
>> @@ -80,8 +81,15 @@ Xdisk(cmd_t *cmd, disk_t *disk, mbr_t *m
>> B B B maxsec B = 999;
>> B #endif
>>
>> + B B if (disk->label)
>> + B B B B B B dmaxcyl = disk->label->cylinders;
>> +
>> B B B /* Ask for new info */
>> B B B if (ask_yn("Change disk geometry?")) {
>> + B B B B B B if (dmaxcyl > maxcyl) {
>> + B B B B B B B B B B printf("Warning setting cyl beyond %u
forces LBA\n", maxcyl);
>> + B B B B B B B B B B maxcyl = dmaxcyl;
>> + B B B B B B }
>>
>
> Since ask_num won't permit numbers > max, how will LBA be forced?
sigh
changing geom doesn't write the disklabel so no, it doesn't force lba,
or anything for that matter.
lba will be forced if you partition beyond cyl 1023 (INDEXED). this is
confirmed by reading part.c ...
"forced" as in fdisk will populate the 4 bit lba word in the mbr
>
>> B B B B B B B disk->real->cylinders = ask_num("BIOS Cylinders",
ASK_DEC,
>> B B B B B B B B B disk->real->cylinders, 1, maxcyl, NULL);
>> B B B B B B B disk->real->heads = ask_num("BIOS Heads", ASK_DEC,
>> Index: src/sbin/fdisk/part.c
>> ===
>> RCS file: /cvs/src/sbin/fdisk/part.c,v
>> retrieving revision 1.50
>> diff -p -u -r1.50 part.c
>> --- src/sbin/fdisk/part.c B B 29 Apr 2009 22:58:24 - B B B 1.50
>> +++ src/sbin/fdisk/part.c B B 4 Jul 2011 20:38:24 -
>> @@ -212,12 +212,10 @@ PRT_parse(disk_t *disk, void *prt, off_t
>> B int
>> B PRT_check_chs(prt_t *partn)
>> B {
>> - B B if ( (partn->shead > 255) ||
>> + B B if ( (partn->shead > 254) ||
>> B B B B B B B (partn->ssect >63) ||
>> - B B B B B B (partn->scyl > 1023) ||
>> - B B B B B B (partn->ehead >255) ||
>> - B B B B B B (partn->esect >63) ||
>> - B B B B B B (partn->ecyl > 1023) )
>> + B B B B B B (partn->ehead >254) ||
>> + B B B B B B (partn->esect >63) )
>> B B B {
>> B B B B B B B return 0;
>> B B B }
>>
>
> Ken
Re: sed behavior
that's not relevant to the example because $ matches the empty string at eol, not the character at eol (.$), which is openbsd sed's interpretation even in the case of certain regex standards that do not allow $ to be used as part of a | expression, the interpretation is faulty On Wed, Jun 15, 2011 at 5:54 PM, Stuart Henderson wrote: > On 2011-06-15, Alexander Hall wrote: >>> This dif fixes your problem here. Big question is of course: does it >>> break other cases? >> >> It differs from perl like this: >> >> $ echo 'l1_1' | perl -pe 's/1|$/X/g' >> lX_XX >> $ echo 'l1_1' | sed -E 's/1|$/X/g' >> lX_X >> >> Meaning we don't hit that final '$' if the last match went to eol. > > perl regular expressions are expected to behave differently > to posix REs.
Re: "no really, be quiet" mode for ping{,6}
On Wed, Apr 6, 2011 at 6:30 AM, Peter Hessler wrote: > On 2011 Apr 06 (Wed) at 12:47:40 +0200 (+0200), David Vasek wrote: > :On Wed, 6 Apr 2011, Peter Hessler wrote: > : > :>Sometimes I want ping to be quiet. B Not quiet in the "only show me > :>headers" way that the original author thought was cute, but in the > :>"don't show me anything" way, so cron doesn't spam me with useless > :>crap. > :> > :>So, in honor of that, here is a patch to add -Q to ping and ping6. > : > :What is the advantage of another button over redirecting stdout and > :error to /dev/null? Is the completely quiet ping used so often? > : > :Regards, > :David > : > > I use silent ping very often (especially in scripts and cronjobs), and it > pisses me off that I need to redirect to /dev/null. B I'm scratching an > itch, here. > > > -- > It's the thought, if any, that counts! > > the shell was supposed to define the interface so that not every program had to recreate it and now ksh has a convenient short-hand: ping google.com >&- the homogeneous -q flags are as problematic as: tar xf - vs. tar xf /dev/stdin seems strange that it was decided to put the - alias inside every and each command that uses it instead of having distinct shorthand for stdout/in through the shell or fs
Re: horribly slow fsck_ffs pass1 performance
On Tue, Apr 5, 2011 at 7:06 AM, Janne Johansson wrote: >> /forcefsck and /fastboot have nothing to do with that >> they are not even administered by the fs >> > I wasn't trying to imply the filesystem is putting the files there, nor > reading them. Rather, those two files show that > "since there is no way to mark known brokeness in a ext file system, we wrap > it up in shell scripts that create and look for > B those files in order to 'know' if the filesystems are broken or not and if > fsck is in order" > sorry, but those files aren't for that purpose. they're just means of queuing fscks and never intended as a viable replacement for dirty flags conversely, openbsd has got /fastboot, yet aptly omits /forcefsck you could say the latter has been avoided because it's a chicken and egg problem, but keep in mind that it forces fsck on all filesystems with a fs_passno greater than zero, not just root, and that / is very unlikely to become corrupted because it's typically split and seldom written to
Re: horribly slow fsck_ffs pass1 performance
On Sun, Apr 3, 2011 at 4:21 AM, Janne Johansson wrote: > 2011/4/2 Benny Lofgren > >> >> I've noticed that some (all?) linux systems do uncalled-for file system >> checks at boot if no check have been made recently, but I've never >> understood this practice. It must mean they don't trust their own file >> systems, >> > > I'm quite sure this comes from the fact that there are several ways for a > ext file system to get errors (which in bash used to show up as > "input/output error" when you try to reference the file) but the filesystem > will not store the error condition anywhere, so if you make a clean > shutdown, and reboot, the fsck will not know that a fsck in due, and skip > over it, and for that whole session until the next reboot, the file is still > as inaccessible as before. > > And since only root may write the "magic" file in the (broken) filesystem > root, a normal user can not force the fsck either, unless he kills the power > switch so the boot scripts know there was an unclean shutdown before, OR, > reboot 147 times (or whatever the intervals may be) so the system does run > the fsck at boot. > > I dont pretent to know the optimal solution for keeping track of "hey, I > just told the user his file is corrupt, I should ask for fsck on the next > mount" but even the early-80s amiga floppy file systems would have a global > "dirty" flag so the OS would launch disk validator next time you inserted > the disk and "mounted" the filesystem if you found out it had some kind of > read/write error. > > Letting users run 1-146 reboot cycles without checking even when you know > stuff is broke is horrid. And having a file inside the actual filesystem to > indicate "if this file isnt deleted it means something" as an inverse flag > really doesnt count (/fastboot or whatever) since if half your files > disappear and that one went also, then its missing status would indicate > "everything is fine". /forcefsck and /fastboot have nothing to do with that they are not even administered by the fs > > -- > B To our sweethearts and wives. B May they never meet. -- 19th century toast
Re: printf(1) null escape
#include
#define CMD "/usr/bin/printf"
int
main(void)
{
execle(CMD, CMD, "\\", NULL, (char *[]){"BROKEN", NULL});
}
On Sat, Apr 2, 2011 at 4:48 AM, Andres Perera wrote:
>
> print_escape returns 1 even if it's on null, and the rest of the
> prog just ignores null literals
>
> $ env -i sh -c '/usr/bin/printf \\'
> printf: unknown escape sequence `\'
> PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
just to be absolutely clear, printf(1) is the one overstepping into
environ[] because of how it badly handles escapes, not the shell
#include
#define CMD "/usr/bin/printf"
int
main(void)
{
execle(CMD, CMD, "\\", NULL, (char *[]){"BROKEN"});
}
here's the plain bug:
$ (./a.out; echo) | vis -l
printf: unknown escape sequence `\'
\^@BROKEN\$
>
> diff -u -r1.17 printf.c
> --- printf.c B B 27 Oct 2009 23:59:41 - B B B 1.17
> +++ printf.c B B 2 Apr 2011 18:44:36 -
> @@ -351,6 +351,11 @@
> B B B B B B B B putchar('\v');
> B B B B B B B B break;
>
> + B B B case '\0':
> + B B B B B B B warnx("null escape sequence");
> + B B B B B B B rval = 1;
> + B B B B B B B return 0;
> +
> B B B B default:
> B B B B B B B B putchar(*str);
> B B B B B B B B warnx("unknown escape sequence `\\%c'", *str);
printf(1) null escape
print_escape returns 1 even if it's on null, and the rest of the
prog just ignores null literals
$ env -i sh -c '/usr/bin/printf \\'
printf: unknown escape sequence `\'
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
diff -u -r1.17 printf.c
--- printf.c27 Oct 2009 23:59:41 - 1.17
+++ printf.c2 Apr 2011 18:44:36 -
@@ -351,6 +351,11 @@
putchar('\v');
break;
+ case '\0':
+ warnx("null escape sequence");
+ rval = 1;
+ return 0;
+
default:
putchar(*str);
warnx("unknown escape sequence `\\%c'", *str);
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 12:51 PM, Pascal Stumpf wrote: > On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: >> On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian >> wrote: >> > my that's awkward. >> > >> >> if you can't combine unix tools, you should be looking at perl. >> >> iru >> >> > > I bet everyone here knows one can achieve the same results with awk, > perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at > fullmoon. That doesn't mean any of those is the easiest or most > convenient tool for the job. Using a fully-blown programming language > just to output a filename and a line matching a regex is plain overkill. > then make the awk line a function or a script don't add more flags to grep that are hard to guess what they do -H for "header"? what does it mean? have you looked at how many flags ls(1) can have? it's a nightmare
Re: [patch] -H flag for grep.
On Mon, Feb 21, 2011 at 7:01 PM, Philip Guenther wrote:
> On Mon, Feb 21, 2011 at 2:30 PM, Fred Crowson wrote:
>> On 02/21/11 15:54, Alexander Schrijver wrote:
> ...
>>> grep(1) only prints the filename when it receives more then 1 filename as
>>> arguments. Thus, when you do this:
>>>
>>> $ find . -name '*.c' -exec grep bla {} \;
>>>
>>> It doesn't print the filename.
>>>
>>> But when you use xargs(1), like Bret suggests it does.
>>
>> $ find . -name "*.php" -exec grep blah {} \; -print
>>
>> Will print the file name after the line that grep matches.
>
> The other classical solution is to always pass multiple filenames by
> including a /dev/null argument:
>
> B find . -name '*.c' -exec grep bla {} /dev/null \;
>
> That works with the xargs case too:
>
> B find . -name '*.c' -print0 | xargs -0 grep bla /dev/null
these two ugly hacks and the the redundant flag have been sought while
what's natural has been overlooked
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
why complicate grep?
>
>
> Philip Guenther
Re: Allegations regarding OpenBSD IPSEC
On Tue, Dec 14, 2010 at 5:54 PM, Theo de Raadt wrote: > I have received a mail regarding the early development of the OpenBSD > IPSEC stack. B It is alleged that some ex-developers (and the company > they worked for) accepted US government money to put backdoors into > our network stack, in particular the IPSEC stack. B Around 2000-2001. Funny how this happened right after the massive wiki leaks. It worked though, most people fell for it.
Re: less stupid kshrc example
2010-10-30 14:34 +0100, Stuart Henderson: > > On 2010/10/29 21:55, Andres Perera wrote: > > Defining a bunch of functions just to update the term title is > > ridiculous. > > I use this. Also it's a good way to find bugs in cwm :) Not sure how it would help, but the title still changes, just not with independent functions. It doesn't work with set -o sh, though, since it doesn't evaluate PS1 escapes in this mode. In that case ksh.kshrc shouldn't be sourced anyway.
less stupid kshrc example
Defining a bunch of functions just to update the term title is
ridiculous.
--- src/etc/ksh.kshrc.orig Fri Oct 29 21:40:51 2010
+++ src/etc/ksh.kshrc Fri Oct 29 21:51:48 2010
@@ -45,16 +45,7 @@
HOSTNAME=${HOSTNAME:-`uname -n`}
HOST=${HOSTNAME%%.*}
- PROMPT="$USER:!$PS1S"
- #PROMPT="<$u...@$host:!>$PS1S"
- PPROMPT='$USER:$PWD:!'"$PS1S"
- #PPROMPT='<$u...@$host:$PWD:!>'"$PS1S"
- PS1=$PPROMPT
- # $TTY is the tty we logged in on,
- # $tty is that which we are in now (might by pty)
- tty=`tty`
- tty=`basename $tty`
- TTY=${TTY:-$tty}
+ PS1='\...@\h:\w \$ '
set -o emacs
@@ -70,82 +61,29 @@
;;
esac
case "$TERM" in
- sun*-s)
- # sun console with status line
- if [ "$tty" != "$console" ]; then
- # ilabel
- ILS='\033]L'; ILE='\033\\'
- # window title bar
- WLS='\033]l'; WLE='\033\\'
- fi
+ dtterm*|screen*|rxvt*|xterm*)
+ ILS="\e]1;"
+ ILE="\a"
+ WLS="\e]2;"
+ WLE="\a"
;;
- xterm*)
- ILS='\033]1;'; ILE='\007'
- WLS='\033]2;'; WLE='\007'
- parent="`ps -ax 2>/dev/null | grep $PPID | grep -v grep`"
- case "$parent" in
- *telnet*)
- export TERM=xterms;;
- esac
+ ''|dumb|vt220)
+ true
;;
- *) ;;
+ *)
+ if tput hs >/dev/null 2>&1; then
+ WLS=`tput ts`
+ WLE=`tput fs`
+ fi
+ ;;
esac
- # do we want window decorations?
- if [ "$ILS" ]; then
- ilabel () { print -n "${ILS}$*${ILE}">/dev/tty; }
- label () { print -n "${WLS}$*${WLE}">/dev/tty; }
-
- alias stripe='label "$u...@$host ($tty) - $PWD"'
- alias istripe='ilabel "$u...@$host ($tty)"'
-
- wftp () { ilabel "ftp $*"; "ftp" "$@"; eval istripe; }
- wcd () { \cd "$@" && eval stripe; }
- wssh ()
- {
- local rc
- "ssh" "$@"
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wtelnet ()
- {
- local rc
- "telnet" "$@"
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wrlogin ()
- {
- local rc
- "rlogin" "$@"
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- wsu ()
- {
- local rc
- "su" "$@"
- rc=$?
- eval istripe
- eval stripe
- return $rc
- }
- alias su=wsu
- alias cd=wcd
- alias ftp=wftp
- alias ssh=wssh
- alias telnet=wtelnet
- alias rlogin=wrlogin
- eval stripe
- eval istripe
- PS1=$PROMPT
+ if [ -n "$ILS" ]; then
+ PS1="$ps1\[$il...@\h$ile\]"
fi
+ if [ -n "$WLS" ]; then
+ PS1="$ps1\[$wl...@\h \w$WLE\]"
+ fi
+ unset ILS ILE WLS WLE
alias quit=exit
alias cls=clear
alias logout=exit
Re: Ralink RT3090 should work now
On Sun, Oct 24, 2010 at 11:14 AM, Andres Perera wrote: > On Sat, Oct 23, 2010 at 10:02 AM, Damien Bergamini > wrote: >> I finally found some time to finish RT3090 support in ral(4). >> If you have such a device, please test the driver in -current >> and report success/failure directly to me. > > Haven't tested it yet, but thanks a ton anyway. > > Will report as soon as I finish syncing cvs. Works great, thanks again.
Re: Ralink RT3090 should work now
On Sat, Oct 23, 2010 at 10:02 AM, Damien Bergamini wrote: > I finally found some time to finish RT3090 support in ral(4). > If you have such a device, please test the driver in -current > and report success/failure directly to me. Haven't tested it yet, but thanks a ton anyway. Will report as soon as I finish syncing cvs.
