Re: [patch] tail(1) follow multiple files
On 5 November 2015 at 00:29, Martijn van Duren wrote:
>
> I got somewhat annoyed by the fact that OpenBSD's tail can't follow multiple
> files and since the last attempt at it was from 2008 I thought I'd give it a
> shot.
Thank you for sharing this, hope it gets accepted.
> (void)printf("%s==> %s <==\n", first ? "" : "\n", fname);
I've recently encountered a problem where I wanted to execute some code for
every new line in a set of files, but the code would be different for each file.
This "==> name <==" format is standard across systems, but it's awkward to
parse. Would OpenBSD be open to a different, non-standard and optional output
format that prefixes each line with "fname:" if there are multiple input files,
much like grep does?
--
The best the little guy can do is what
the little guy does right
Re: Want to help upstream software improve their random?
On 11 December 2014 at 21:43, Theo de Raadt wrote: > > > On 12 Dec 2014, at 5:02, Theo de Raadt wrote: > > > > > In all of these code blocks are a well-known piece of information > > > (same time on your machine as everywhere else) is being used to seed a > > > deterministic number generator. > > > > > > At some later point, deterministic numbers are taken out using rand(), > > > random(), drand48(), lrand48(), mrand48(), or srand48(), or some > > > derivative function inside the program itself, and used for WHO KNOWS > > > WHAT PURPOSE. > > > > > > I did not audit what the numbers are being used for. > > > > > > Quite likely some numbers are just used to help hashing. Some could > > > be used to print pretty pictures. But in xulrunner? In the zip > > > password > > > creator? In postgresql, or say in openldap (a network related thing)? > > > > > > It is doubtful they are all fine. > > > > > > For the benefit of other projects who haven't taken the same steps as > > > OpenBSD, it would be nice if some people helped out these pieces of > > > software. > > > > > > EMBOSS-6.0.1srand((unsigned) time(&tm)); > > [...] > > > > What you say makes sense. Is there a best practice alternative you > > suggest or did I miss that? Perhaps just some better initiation value, > > preferably not all from the same place? > > These code sequences do not need deterministic values. They actually > want non-deterministic values. Steps are like this: > > 1. Remove the srand(), srandom(), srand48(), seed48(), > lcong48() calls. > > 2. Replace all rand(), random(), lrand48(), mrand48() calls with > arc4random() > > 3. If the calls use %, consider using arcrandom_uniform() instead. > > 4. If it loops to fill a buffer, use arc4random_buf() > > 5. Replace drand48() with arc4random and some floating point, but > be careful. drand48() is very rare. > > Now, talk to the upstream projects. They will reject your changes > because Linux lacks arc4random(). > > Basically, only Linux and Solaris lack arc4random(). All the other > platforms have it. > > There are libraries available which provide arc4random() on Linux, so > maybe you find an upstream software provider who is willing to create > a dependency on such a library on Linux. > > Lots of software is doing precisely that, so don't be afraid. > > Thank you. Are there any specific good libraries you know of? -- The best the little guy can do is what the little guy does right
Re: chmod.c undefined behavior
Can you two please continue this spam off-list, or at least in misc? On 24 September 2014 23:52, Matti Karnaattu wrote: > > You were probably trained in the Object-oriented (and likely a bit of > post-OO) tradition. Most likely you learned > > Java, and then possibly either C# or Ruby. > > I started C-64 Basic, then I learned assembler, then C. > > After C, I have learned bunch object oriented and functional > languages. Lately I have programmed in Typescript. > > I actually switch language to another all the time. Language is a tool > and similar patterns can be implemented everywhere. > > >OO is not the only valid way to program. > > I agree. Usually, I'm thinking functional approach first, and if that > doesn't cut, I look problem from dataflow perspective and after that I > try OO. That usually solve the problem if everything else fails but > that it is not of course only way. > > >I don't always agree with the OpenBSD developers (and sometimes I > vehemently disagree with their take on >things), but as a user I'm much > happier with the quality, consistency and predictability that OpenBSD > provides, than >with some project that's always chasing the moving target > of the perfect programming paradigm. > > I also like how directory structure is done in that scale and that > consistency that ~everything is C and sh scripts. > > >and so perhaps more familiar to many modern programmers, but not > intrinsically or automatically more readable. > > I don't afraid of long functions. I also write long functions if I > have fully implemented DbC or there is just lot to do. > > However, I do avoid complex functions. > > > and it's highly unlikely that any random group of programmers will be > willing to follow the style you were trained to > think is "best". > > "best" is not "best" if it is not possible to measure it any practical way. > > I can measure speed, I can measure memory usage, I can even measure > how much implementation uses energy (which is actually good optimum > for speed/memory usage) but I agree that coding style is often a > matter of opinion. > > However, there is some factors that actually can be measured and those > tells something about quality. Example, > > -Code coverage in tests (complex code is not easy to test!) > -Cyclomatic complexity > -Coupling > > Relating to coding style, it can't practically measure what is better > name for function. Despite for that, > I consider naming convention extemely important, because that is part > of the process that is not so straightforward but I don't ever start > argue how to shorten names or is camelCase better. I don't care as > long as the style doesn't change. > > >OpenBSD defines (AFAIK) "results" to include safety of code, and/or > freedom from unanticipated side-effects (i.e. >bugs). > > I'm fascinated many ways the clean source tree in that scale and I > have personal itch to implement methods to find bugs. > > Instead of pointing out single bug, I'm thinking about implementing > methods to make much as possible bugs in code visible. > > -- The best the little guy can do is what the little guy does right
Re: usermod: lock/unlock local password
On 11 September 2012 09:37, Antoine Jacoutot wrote: > On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote: >> On 10 September 2012 18:01, Antoine Jacoutot wrote: >> > Hi. >> > >> > This diff adds 2 new options to usermod(8): >> > -U to unlock a user's password >> > -Z to lock a user's password >> > >> > In effect locking/unlocking the password means to add a '!' in front of >> > the encrypted entry in master.passwd. >> > Note that this disable the _password_ not the account of course (you >> > could still connect using ssh+key for e.g.). >> > >> > That said, I have some use for it and would like to be able to have this >> > if at all possible. >> > Behavior is basically the same as Linux's usermod(8) except that I am >> > using -Z for locking the password (-Z is for SElinux in Linux land and >> > -L is used instead but we use it ourselves for the login class). >> > >> > Comments? >> >> Hi, >> >> Isn't think better placed in passwd? >> At least Linux and Solaris (since 5.6 i believe) have this as -l and >> -u in passwd(1), >> so this might be a better option to keep it consistent with other >> systems. HP-UX >> only implements -l; I haven't checked others. > > It is consistent; this is how usermod works in linux as well. Isn't it better to be consistent with most Unix systems and not just Linux? The world is Linux-centric enough already and an OpenBSD should know it better than anyone else ;) >> OpenBSD passwd already uses -l to restrict passwd to local files only though >> so >> you would still need to use a different letter (as you do with >> usermod) but at least >> passwd(1) is where most unix admins would look for this option first. > > This diff is for the usermod part, not passwd; both are different things. I don't get it - how are they "different things"? Both manipulate shadow. -- The best the little guy can do is what the little guy does right
Re: usermod: lock/unlock local password
On 10 September 2012 18:01, Antoine Jacoutot wrote:
> Hi.
>
> This diff adds 2 new options to usermod(8):
> -U to unlock a user's password
> -Z to lock a user's password
>
> In effect locking/unlocking the password means to add a '!' in front of
> the encrypted entry in master.passwd.
> Note that this disable the _password_ not the account of course (you
> could still connect using ssh+key for e.g.).
>
> That said, I have some use for it and would like to be able to have this
> if at all possible.
> Behavior is basically the same as Linux's usermod(8) except that I am
> using -Z for locking the password (-Z is for SElinux in Linux land and
> -L is used instead but we use it ourselves for the login class).
>
> Comments?
>
>
>
>
>
> Index: user.c
> ===
> RCS file: /cvs/src/usr.sbin/user/user.c,v
> retrieving revision 1.90
> diff -u -r1.90 user.c
> --- user.c 29 Jan 2012 08:38:54 - 1.90
> +++ user.c 10 Sep 2012 15:00:21 -
> @@ -100,7 +100,9 @@
> F_UID = 0x0400,
> F_USERNAME = 0x0800,
> F_CLASS = 0x1000,
> - F_SETSECGROUP = 0x4000
> + F_SETSECGROUP = 0x4000,
> + F_PWLOCK= 0x8000,
> + F_PWUNLOCK = 0x1
> };
>
> #define CONFFILE "/etc/usermgmt.conf"
> @@ -1339,11 +1341,14 @@
> struct group*grp;
> const char *homedir;
> charbuf[LINE_MAX];
> + charlocked_str[] = "!";
> + charpw_len[PasswordLength + 1];
> size_t colonc, loginc;
> size_t cc;
> FILE*master;
> charnewdir[MaxFileNameLen];
> char*colon;
> + char*pw_tmp;
> int len;
> int masterfd;
> int ptmpfd;
> @@ -1359,6 +1364,9 @@
> if (!is_local(login_name, _PATH_MASTERPASSWD)) {
> errx(EXIT_FAILURE, "User `%s' must be a local user",
> login_name);
> }
> + if ((up->u_flags & (F_PWLOCK | F_PWUNLOCK)) && (pwp->pw_uid == 0)) {
> + errx(EXIT_FAILURE, "(un)locking is not supported for `%s'",
> pwp->pw_name);
> + }
> /* keep dir name in case we need it for '-m' */
> homedir = pwp->pw_dir;
>
> @@ -1410,6 +1418,29 @@
> pwp->pw_passwd = up->u_password;
> }
> }
> + if (up->u_flags & F_PWLOCK) {
> + if (strncmp(pwp->pw_passwd, locked_str,
> sizeof(locked_str)-1) == 0) {
> +warnx("user '%s' is already locked",
> pwp->pw_name);
> + } else {
> + pw_tmp = malloc(strlen(pwp->pw_passwd) +
> sizeof(locked_str));
> + if (pw_tmp == NULL) {
> + (void) close(ptmpfd);
> + pw_abort();
> + errx(EXIT_FAILURE, "cannot allocate
> memory");
> + }
> + strlcpy(pw_tmp, locked_str, sizeof(pw_len));
> + strlcat(pw_tmp, pwp->pw_passwd,
> sizeof(pw_len));
> + pwp->pw_passwd = pw_tmp;
> + free (pw_tmp);
> + }
> + }
> + if (up->u_flags & F_PWUNLOCK) {
> + if (strncmp(pwp->pw_passwd, locked_str,
> sizeof(locked_str)-1) != 0) {
> + warnx("user '%s' is not locked",
> pwp->pw_name);
> + } else {
> + pwp->pw_passwd += sizeof(locked_str)-1;
> + }
> + }
> if (up->u_flags & F_UID) {
> /* check uid isn't already allocated */
> if (!(up->u_flags & F_DUPUID) &&
> getpwuid((uid_t)(up->u_uid)) != NULL) {
> @@ -1617,7 +1648,7 @@
> "[-p password] [-r low..high]\n"
> " [-s shell] [-u uid] user\n", prog);
> } else if (strcmp(prog, "usermod") == 0) {
> - (void) fprintf(stderr, "usage: %s [-mov] "
> + (void) fprintf(stderr, "usage: %s [-UZmov] "
> "[-c comment] [-d home-directory] [-e expiry-time]\n"
> " [-f inactive-time] "
> "[-G secondary-group[,group,...]]\n"
> @@ -1788,7 +1819,7 @@
> free(u.u_primgrp);
> u.u_primgrp = NULL;
> have_new_user = 0;
> - while ((c = getopt(argc, argv, "G:L:S:c:d:e:f:g:l:mop:s:u:v")) != -1)
> {
> + while ((c = getopt(argc, argv, "G:L:S:UZc:d:e:f:g:l:mop:s:u:v")) !=
> -1) {
> switch(c) {
> case 'G':
>
Re: ThinkPad T60 x86emu panic on resume (w/patch)
On 2 September 2012 21:13, Theo de Raadt wrote:
>> Index: vga_pci.c
>> ===
>> RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
>> retrieving revision 1.68
>> diff -u -r1.68 vga_pci.c
>> --- vga_pci.c 22 Aug 2012 20:58:30 - 1.68
>> +++ vga_pci.c 2 Sep 2012 17:42:09 -
>> @@ -186,7 +186,13 @@
>> { 0x, 0x, 0x, 0x }, 1, 0
>> },
>>
>> - { /* All ATI video until further notice */
>> + {
>> + { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1400,
>> + 0x, 0x },
>> + { 0x, 0x, 0x, 0x}, 0, 0
>> + },
>> +
>> + { /* Other ATI video until further notice */
>> { PCI_VENDOR_ATI, 0x,
>> 0x, 0x },
>> { 0x, 0x, 0x, 0x}, 1, 0
>
>
> That's a great patch, because it doesn't find or fix the underlying
> issues.
>
> Then, when the next person -- who's video did need this -- finds out
> it no longer works, they can submit the inverse of your diff -- once
> again not undercovering the real issue. Of course, now it is their
> problem, not yours, right?
>
> Your diff can be summarized as "make it work for me, me, me, me".
> Awesome work. You know how to fix it just for yourself and submit a
> self-serving patch, hoping we'll commit it without looked deeper, so
> truly you are now an open source wizard.
>
> /sarcasm
>
This is as unfair as it gets. Did i somehow miss the bit where Alexander
asks for OKs? I think this diff merely shows that he nailed it down to
specific piece of code. He gets a panic so how is his problem even 'fixed'?
Do not assume everyone around you is silly and ill-intended.
Re: [heads up] X snapshots now contain libxcb
2009/8/4 Matthieu Herrb : > Hi > > X snapshots dated aug 3 and later are now built with XCB enabled. > So libxcb and all the other xcb libs are provided, and libX11 now > depends on it. Its major revision number has been incremented (it's now > libX11.so.12.0) to avoid mixing things. > > You will have to wait a bit until binary packages for your favourite > architectures are updated to be able to really use them for new installs > or upgrade. Thanks for your work, that was a long awaited change for me! -- The best the little guy can do is what the little guy does right
ripd split-horizon configuration diff
This diff changes the configuration format of the split-horizon option
of ripd. This involves no behavior change, only configuration.
The old way was to give choice among three possible variants:
split-horizon default
split-horizon poisoned
split-horizon none
And the default behavior was "split-horizon none". This is kind of
confusing, imho, to have "default" which is not default ;)
And this "default" actually just means that split-horizon is on.
With this diff you have the same three options, but with other names:
split-horizon yes
split-horizon poisoned
split-horizon no
And the default is still "no", but there is no "default", which isn't,
actually, the default behavior.
btw, why is "no" default? most networks will only benefit from "yes" or
poison-reverse. It causes troubles only under certain and rare
conditions, but, you know, this conditions will make rip network
almost unusable anyway.
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ripd/parse.y,v
retrieving revision 1.24
diff -u -p -r1.24 parse.y
--- parse.y 31 Mar 2009 21:03:49 - 1.24
+++ parse.y 30 Jul 2009 22:34:31 -
@@ -157,9 +157,9 @@ conf_main : SPLIT_HORIZON STRING {
/* clean flags first */
conf->options &= ~(OPT_SPLIT_HORIZON |
OPT_SPLIT_POISONED);
- if (!strcmp($2, "none"))
+ if (!strcmp($2, "no"))
/* nothing */ ;
- else if (!strcmp($2, "default"))
+ else if (!strcmp($2, "yes"))
conf->options |= OPT_SPLIT_HORIZON;
else if (!strcmp($2, "poisoned"))
conf->options |= OPT_SPLIT_POISONED;
Index: printconf.c
===
RCS file: /cvs/src/usr.sbin/ripd/printconf.c,v
retrieving revision 1.5
diff -u -p -r1.5 printconf.c
--- printconf.c 24 Mar 2009 19:26:13 - 1.5
+++ printconf.c 30 Jul 2009 22:34:31 -
@@ -44,11 +44,11 @@ print_mainconf(struct ripd_conf *conf)
print_redistribute(conf);
if (conf->options & OPT_SPLIT_HORIZON)
- printf("split-horizon default\n");
+ printf("split-horizon yes\n");
else if (conf->options & OPT_SPLIT_POISONED)
printf("split-horizon poisoned\n");
else
- printf("split-horizon none\n");
+ printf("split-horizon no\n");
if (conf->options & OPT_TRIGGERED_UPDATES)
printf("triggered-updates yes\n");
Index: ripd.conf.5
===
RCS file: /cvs/src/usr.sbin/ripd/ripd.conf.5,v
retrieving revision 1.9
diff -u -p -r1.9 ripd.conf.5
--- ripd.conf.5 17 Dec 2008 15:47:30 - 1.9
+++ ripd.conf.5 30 Jul 2009 22:34:31 -
@@ -122,12 +122,12 @@ will force the route to be not announced
.It Xo
.Ic split-horizon
.Sm off
-.Po Ic default Ns \&| Ns Ic poisoned Ns \&| Ns
-.Ic none Pc
+.Po Ic yes Ns \&| Ns Ic poisoned Ns \&| Ns
+.Ic no Pc
.Sm on
.Xc
If set to
-.Ic default ,
+.Ic yes ,
do not redistribute routes to the interface from which they were learned.
If set to
.Ic poisoned ,
@@ -135,7 +135,7 @@ redistribute routes to the interface fro
forcing the metric to infinity.
Both these behaviours can resolve routing loops when a router goes down.
The default is
-.Ic none .
+.Ic no .
.Pp
.It Xo
.Ic triggered-updates
--
The best the little guy can do is what
the little guy does right
