Re: [patch] tail(1) follow multiple files

2015-11-05 Thread Eugene Yunak
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?

2014-12-11 Thread Eugene Yunak
On 11 December 2014 at 21:43, Theo de Raadt dera...@cvs.openbsd.org 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

2014-09-24 Thread Eugene Yunak
Can you two please continue this spam off-list, or at least in misc?

On 24 September 2014 23:52, Matti Karnaattu mkarnaa...@gmail.com 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

2012-09-11 Thread Eugene Yunak
On 10 September 2012 18:01, Antoine Jacoutot ajacou...@bsdfrog.org 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':
 while ((u.u_groupv[u.u_groupc] = strsep(optarg, 
 ,)) != NULL 
 @@ -1814,6 +1845,12 @@
 }
 u.u_flags |= 

Re: usermod: lock/unlock local password

2012-09-11 Thread Eugene Yunak
On 11 September 2012 09:37, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
 On Tue, Sep 11, 2012 at 09:33:56AM +0300, Eugene Yunak wrote:
 On 10 September 2012 18:01, Antoine Jacoutot ajacou...@bsdfrog.org 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: ThinkPad T60 x86emu panic on resume (w/patch)

2012-09-02 Thread Eugene Yunak
On 2 September 2012 21:13, Theo de Raadt dera...@cvs.openbsd.org 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.



ripd split-horizon configuration diff

2009-07-30 Thread Eugene Yunak
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