Re: netcat: bump BUFSIZE to 64k?

2022-12-18 Thread Loganaden Velvindron
On Sun, 18 Dec 2022 at 17:01, Theo Buehler  wrote:
>
> This is the remaining bit of mpf's recent netcat diff. The commit log
> shows that it was bumped to 64k in the past, but that was promptly
> reverted due to concerns of buffer bloat caused by atomicio blocking
> traffic in the other direction.
>
> I don't know if things are different enough 8 years later that this can
> be reconsidered. Not my area, just throwing it out there so it doesn't
> get lost.
>

If there's a push to reduce bufferbloat, then maybe have a look at this too:

https://datatracker.ietf.org/doc/id/draft-gettys-iw10-considered-harmful-00.html

Maybe revert IW from 10 to 4 :-) ?

> Index: netcat.c
> ===
> RCS file: /cvs/src/usr.bin/nc/netcat.c,v
> retrieving revision 1.224
> diff -u -p -r1.224 netcat.c
> --- netcat.c18 Dec 2022 12:53:18 -  1.224
> +++ netcat.c18 Dec 2022 12:54:58 -
> @@ -66,7 +66,7 @@
>  #define POLL_NETOUT1
>  #define POLL_NETIN 2
>  #define POLL_STDOUT3
> -#define BUFSIZE16384
> +#define BUFSIZE65536
>
>  #define TLS_NOVERIFY   (1 << 1)
>  #define TLS_NONAME (1 << 2)
>



Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)

2022-11-06 Thread Loganaden Velvindron
On Sun, 6 Nov 2022 at 18:31, Job Snijders  wrote:
>
> Dear all,
>
> Support for using Ed25519 for server and user authentication was
> introduced in 2014. I like the compactness of Ed25519 public keys.
>
> Perhaps now is a good time to make Ed25519 the default key type when
> invoking ssh-keygen(1) without arguments?
>

I agree, but I think we lack data on deployed ssh systems at large.

> Kind regards,
>
> Job
>
> Index: ssh-keygen.1
> ===
> RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
> retrieving revision 1.226
> diff -u -p -r1.226 ssh-keygen.1
> --- ssh-keygen.110 Sep 2022 08:50:53 -  1.226
> +++ ssh-keygen.16 Nov 2022 13:31:19 -
> @@ -185,7 +185,7 @@ The type of key to be generated is speci
>  option.
>  If invoked without any arguments,
>  .Nm
> -will generate an RSA key.
> +will generate an ed25519 key.
>  .Pp
>  .Nm
>  is also used to generate groups for use in Diffie-Hellman group
> Index: ssh-keygen.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v
> retrieving revision 1.459
> diff -u -p -r1.459 ssh-keygen.c
> --- ssh-keygen.c11 Aug 2022 01:56:51 -  1.459
> +++ ssh-keygen.c6 Nov 2022 13:31:21 -
> @@ -61,12 +61,6 @@
>  #include "ssh-pkcs11.h"
>  #endif
>
> -#ifdef WITH_OPENSSL
> -# define DEFAULT_KEY_TYPE_NAME "rsa"
> -#else
> -# define DEFAULT_KEY_TYPE_NAME "ed25519"
> -#endif
> -
>  /*
>   * Default number of bits in the RSA, DSA and ECDSA keys.  These value can be
>   * overridden on the command line.
> @@ -252,7 +246,7 @@ ask_filename(struct passwd *pw, const ch
> char *name = NULL;
>
> if (key_type_name == NULL)
> -   name = _PATH_SSH_CLIENT_ID_RSA;
> +   name = _PATH_SSH_CLIENT_ID_ED25519;
> else {
> switch (sshkey_type_from_name(key_type_name)) {
> case KEY_DSA_CERT:
> @@ -3748,7 +3742,7 @@ main(int argc, char **argv)
> }
>
> if (key_type_name == NULL)
> -   key_type_name = DEFAULT_KEY_TYPE_NAME;
> +   key_type_name = "ed25519";
>
> type = sshkey_type_from_name(key_type_name);
> type_bits_valid(type, key_type_name, );
>



Re: Recommended EDNS buffer sizes for nsd and unbound

2019-09-18 Thread Loganaden Velvindron
On Wed, Sep 18, 2019 at 5:56 PM Florian Obser  wrote:
>
> On Tue, Sep 17, 2019 at 08:19:29PM +0400, logan wrote:
> > Hi All,
> >
> > There was a presentation about fragmentation attacks against DNS:
> > https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf
> >
> > DNS Flag day 2020 recommends 1232 to avoid fragmentation in most
> > common setups.
> >
>
> What is upstream's stance on this?
>

They are still discussing the issue.



> > Index: src/etc/nsd.conf
> > ===
> > RCS file: /cvs/src/etc/nsd.conf,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 nsd.conf
> > --- src/etc/nsd.conf  16 Aug 2018 17:59:12 -  1.13
> > +++ src/etc/nsd.conf  17 Sep 2019 15:43:48 -
> > @@ -17,6 +17,11 @@ server:
> >  ## on by default
> >  #refuse-any: yes
> >
> > +## respond with a small EDNS buffer size to avoid
> > +## fragmentation attacks leading to spoofed DNS packets.
> > +#ipv4-edns-size: 1232
> > +#ipv6-edns-size: 1232
> > +
> >  remote-control:
> >   control-enable: yes
> >   control-interface: /var/run/nsd.sock
> >
> >
> > Index: src/etc/unbound.conf
> > ===
> > RCS file: /cvs/src/etc/unbound.conf,v
> > retrieving revision 1.17
> > diff -u -p -r1.17 unbound.conf
> > --- src/etc/unbound.conf  25 Aug 2019 15:50:21 -  1.17
> > +++ src/etc/unbound.conf  17 Sep 2019 15:43:32 -
> > @@ -39,9 +39,9 @@ server:
> >
> >   # UDP EDNS reassembly buffer advertised to peers. Default 4096.
> >   # May need lowering on broken networks with fragmentation/MTU issues,
> > - # particularly if validating DNSSEC.
> > - #
> > - #edns-buffer-size: 1480
> > + # particularly if validating DNSSEC.
> > + # A value around 1232 is recommended to avoid fragmentation attacks.
> > + #edns-buffer-size: 1232
> >
> >   # Use TCP for "forward-zone" requests. Useful if you are making
> >   # DNS requests over an SSH port forwarding.
> >
>
> --
> I'm not entirely sure you are real.
>



Re: I have a program I wish to submit for the base

2016-01-31 Thread Loganaden Velvindron
On Mon, Feb 1, 2016 at 6:18 AM, Luke Small  wrote:

> I fixed the uname(1) call and replaced it with uname(3) I read the style
> man page. ran the program through indent.
>
>
2 seasoned OpenBSD developers have taken time to reply to you, and they do
not like the general idea. No seasoned OpenBSD developer has shown any
interest. I suggest you drop the discussion.


Re: I have a program I wish to submit for the base

2016-01-29 Thread Loganaden Velvindron
On Fri, Jan 29, 2016 at 12:44 PM, Jérémie Courrèges-Anglas 
wrote:

> Luke Small  writes:
>
> > I wanted to use kqueue. Name another script or programming language that
> > offers it from the base install. NONE!
>
>
>
Hi Luke,

I understand your perspective. If you use OpenBSD already, then I would
suggest you start by fixing bugs in documentation as you encounter them or
small fixes, as a start.

Look at what OpenBSD is currently heading: tame, improvements to OpenBGPd,
and the crazy W^X stuff.

(url: http://www.openbsd.org/papers/).

If you are looking to work for something interesting, here is a good start.
Run -current, and if you encounter a bug, try fixing it, and think about
ways to improve your small fixes.


[PATCH] pledging dhclient

2015-11-02 Thread Loganaden Velvindron
Hi guys,

I've been playing with pledge in base. Here's a small patch for dhclient.
It's still a WiP.

I can kill -HUP dhclient, and so far no issues.

I would like it to pledge before however, so that write operations (write_*)
that take their input from the network are further tightened down. One
of the vulnerabilities in ISC dhcp was a stack overflow due to unchecked
condititions when writing to files.

I was thinking about pledging the privchild proces. Or that might be 
overkill ?

fork_privchld(int fd, int fd2) is calling dispatch_imsg() which contains the
write operations to files.


Feedback welcomed:

Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.365
diff -u -p -r1.365 dhclient.c
--- dhclient.c  26 Oct 2015 16:32:33 -  1.365
+++ dhclient.c  2 Nov 2015 07:11:15 -
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *path_dhclient_conf = _PATH_DHCLIENT_CONF;
 char *path_dhclient_db = NULL;
@@ -595,6 +596,10 @@ main(int argc, char *argv[])
endpwent();
 
setproctitle("%s", ifi->name);
+
+   if (pledge("stdio dns route inet proc", NULL) == -1)
+   error("pledge");
+
time(>startup_time);
 
if (ifi->linkstat) {



Re: bzero() -> explicit_bzero() in bgpd(8)

2015-09-10 Thread Loganaden Velvindron
On Thu, Sep 10, 2015 at 6:36 PM, Michael McConville <
mmcco...@sccs.swarthmore.edu> wrote:

> These seem like they were definitely meant to be explicit zeroings.
>
> Hi,

I'm not entirely sure about this. Since the variable (data) is used before
return, it would not be optimized away by the compiler.

A case where optimization would happen would be:

bzero(data,len);
return (-1);


Or maybe I'm wrong here ?



>
> Index: pfkey.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/pfkey.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 pfkey.c
> --- pfkey.c 10 Feb 2015 05:18:39 -  1.44
> +++ pfkey.c 10 Sep 2015 18:35:12 -
> @@ -464,14 +464,14 @@ pfkey_reply(int sd, u_int32_t *spip)
> len = hdr.sadb_msg_len * PFKEY2_CHUNK;
> if (read(sd, data, len) != len) {
> log_warn("pfkey read");
> -   bzero(data, len);
> +   explicit_bzero(data, len);
> free(data);
> return (-1);
> }
>
> if (hdr.sadb_msg_type == SADB_GETSPI) {
> if (spip == NULL) {
> -   bzero(data, len);
> +   explicit_bzero(data, len);
> free(data);
> return (0);
> }
> @@ -489,7 +489,7 @@ pfkey_reply(int sd, u_int32_t *spip)
> }
> }
> }
> -   bzero(data, len);
> +   explicit_bzero(data, len);
> free(data);
> return (0);
>  }
>
>


LibreSSL 2038 problem

2015-06-10 Thread Loganaden Velvindron
Hi folks,

I read that 64-bit time issues have been fixed in LibreSSL, and that
it is 2038 ready. We need to create certificates on 64-bit systems
using RFC3779 that are valid beyond year 2038. RFC3779 support was
removed in LibreSSL, back in release 2.1.4.

I was wondering if there would be argument against bringing back RFC3779 ?


Kind regards,
//Logan
C-x-C-c



Re: [patch 1/3] ksh: add overflow checking for memory allocations

2015-05-23 Thread Loganaden Velvindron
On Sat, May 23, 2015 at 12:28 PM, Theo Buehler t...@math.ethz.ch wrote:
 This set of three patches adds overflow checking to ksh in the spirit
 of the malloc(A*B) - reallocarray(NULL, A, B) conversions that were
 ongoing since last summer.  I've been running these patches on my main
 laptop since January on amd64/CURRENT and didn't notice any issues.

 ksh has its own memory management functions and only calls malloc and
 realloc in the functions alloc() and aresize() in alloc.c.  There the
 `size' arguments have the form

 sizeof(struct link) + size

 where struct link is defined as

 struct link {
 struct link *prev;
 struct link *next;
 };

 In order to ensure that this doesn't overflow if `size' is a product of
 two numbers, wrap alloc() and aresize() into two functions which take
 the two factors as arguments and take care of the overflow checking:

 void *allocarray(size_t nmemb, size_t size, Area *ap);
 void *aresizearray(void *ptr, size_t nmemb, size_t size, Area *ap);

 The mathematically optimal check would test whether at least one of
 `size' and `nmemb' exceeds `sqrt(SIZE_MAX - sizeof(nmemb))' before
 proceeding.  I went for something which is easier to compute.

 This first patch introduces the two wrappers and adds the overflow
 checking.

 The other two patches consist of purely mechanical conversions:

 Expand the macro

 #define sizeofN(type, n) (sizeof(type) * n)

 and take care of all explicit multiplications.


Hi, Please don't forget to include Otto's license to the code, that
you modified.


 Index: alloc.c
 ===
 RCS file: /cvs/src/bin/ksh/alloc.c,v
 retrieving revision 1.8
 diff -u -p -r1.8 alloc.c
 --- alloc.c 21 Jul 2008 17:30:08 -  1.8
 +++ alloc.c 23 May 2015 11:58:27 -
 @@ -74,6 +74,33 @@ alloc(size_t size, Area *ap)
 return L2P(l);
  }

 +/*
 + * This is sqrt(SIZE_MAX+1), as s1*s2 = SIZE_MAX
 + * if both s1  MUL_NO_OVERFLOW and s2  MUL_NO_OVERFLOW
 + */
 +#define MUL_NO_OVERFLOW((size_t)1  (sizeof(size_t) * 4))
 +/*
 + * Generous upper bound for sqrt(sizeof(struct link)).
 + */
 +#define SQRT_SIZ_STR_LINK (sizeof(struct link) / 2)
 +
 +void *
 +allocarray(size_t nmemb, size_t size, Area *ap)
 +{
 +   /*
 +* Ensure that `sizeof(struct link) + size * nmemb' doesn't overflow.
 +* If overflow occurs, at least one of `size' and `nmemb' must be
 +* larger than sqrt(SIZE_MAX - sizeof(struct link)).
 +* Note: sqrt(a - b)  sqrt(a) - sqrt(b) for a  b.
 +*/
 +   if ((nmemb = MUL_NO_OVERFLOW - SQRT_SIZ_STR_LINK ||
 +   size = MUL_NO_OVERFLOW - SQRT_SIZ_STR_LINK) 
 +   nmemb  0  (SIZE_MAX - sizeof(struct link)) / nmemb  size)
 +   internal_errorf(1, unable to allocate memory);
 +
 +   return (alloc(size * nmemb, ap));
 +}
 +
  void *
  aresize(void *ptr, size_t size, Area *ap)
  {
 @@ -97,6 +124,18 @@ aresize(void *ptr, size_t size, Area *ap
 lnext-prev = l2;

 return L2P(l2);
 +}
 +
 +void *
 +aresizearray(void *ptr, size_t nmemb, size_t size, Area *ap)
 +{
 +   /* Ensure that `sizeof(struct link) + size * nmemb' doesn't overflow. 
 */
 +   if ((size = MUL_NO_OVERFLOW - SQRT_SIZ_STR_LINK ||
 +   nmemb = MUL_NO_OVERFLOW - SQRT_SIZ_STR_LINK) 
 +   nmemb  0  (SIZE_MAX - sizeof(struct link)) / nmemb  size)
 +   internal_errorf(1, unable to allocate memory);
 +
 +   return (aresize(ptr, size * nmemb, ap));
  }

  void
 Index: proto.h
 ===
 RCS file: /cvs/src/bin/ksh/proto.h,v
 retrieving revision 1.35
 diff -u -p -r1.35 proto.h
 --- proto.h 4 Sep 2013 15:49:19 -   1.35
 +++ proto.h 23 May 2015 11:58:27 -
 @@ -10,7 +10,9 @@
  Area * ainit(Area *);
  void   afreeall(Area *);
  void * alloc(size_t, Area *);
 +void * allocarray(size_t, size_t, Area *);
  void * aresize(void *, size_t, Area *);
 +void * aresizearray(void *, size_t, size_t, Area *);
  void   afree(void *, Area *);
  /* c_ksh.c */
  intc_hash(char **);
 Index: sh.h
 ===
 RCS file: /cvs/src/bin/ksh/sh.h,v
 retrieving revision 1.33
 diff -u -p -r1.33 sh.h
 --- sh.h18 Dec 2013 13:53:12 -  1.33
 +++ sh.h23 May 2015 11:58:27 -
 @@ -15,6 +15,7 @@
  #include setjmp.h
  #include stdbool.h
  #include stddef.h
 +#include stdint.h
  #include stdlib.h
  #include unistd.h
  #include string.h




Re: seccomp system call

2015-05-03 Thread Loganaden Velvindron
On Sun, May 3, 2015 at 8:18 PM, Nicolas Bedos nicolas.be...@gmail.com wrote:
 I am wondering if the seccomp system call [1] would be welcomed in the
 OpenBSD tree. I remember it was among the subjects of last year's Google
 Summer of Code. If there is still interest in having it implemented, I
 am willing to work on it: I have a diff that creates the system call and
 allows seccomp to be called with the SECCOMP_SET_MODE_STRICT operation.
 It's a first step, the next (big) one would be BPF(4) syscall filtering.


 [1] http://man7.org/linux/man-pages/man2/seccomp.2.html


OpenBSD already has systrace.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/systrace.4?query=systracearch=i386

If you have interest in this kind of stuff, I would advise looking at
what is done in sshd, and more recently, file(1).

(for file(1): see
http://www.freshbsd.org/commit/openbsd/95b5f38db7636a4aaf9af03aaf0bd2019f8aa6cf).



Re: fread optimization

2015-01-21 Thread Loganaden Velvindron
On Wed, Jan 21, 2015 at 5:42 PM, enh e...@google.com wrote:
 On Wed, Jan 21, 2015 at 3:04 AM, Martin Pieuchot mpieuc...@nolizard.org 
 wrote:
 Hello Elliott,

 On 20/01/15(Tue) 16:15, enh wrote:
 that patch wasn't setting the _flags right on error or eof.

 Thanks!  Below is a version of your diff with some tweaks to match the
 recent changes done in -current.

 In your original post you've shown some test numbers.  Does it mean that
 you have a test program for fread(3)?  If so do you think it would fit as
 test in OpenBSD's regress framework?

 we have over a thousand C library tests and a small number of
 benchmarks in bionic/tests and bionic/benchmarks in the Android tree,
 all BSD-licensed. (though this only amounts to 42% coverage.)

 I'd suggest you to check the setup of your mail client, apparently it
 eats all the tabs and makes impossible to apply your diffs correctly :)

 afaik, there's nothing to can do to stop gmail eating tabs.

Check out devio.us if you need a shell account, to send diffs to OpenBSD.



 Index: fread.c
 ===
 RCS file: /home/ncvs/src/lib/libc/stdio/fread.c,v
 retrieving revision 1.13
 diff -u -p -r1.13 fread.c
 --- fread.c 8 Dec 2014 20:40:53 -   1.13
 +++ fread.c 21 Jan 2015 10:54:56 -
 @@ -37,18 +37,19 @@
  #include errno.h
  #include local.h

 +#define MINIMUM(a, b)  (((a)  (b)) ? (a) : (b))

 you don't want to use the MIN from sys/param.h? many files in libc
 already do. (though admittedly fvwrite.c defines its own, but that
 seems like a bug.)

  #define MUL_NO_OVERFLOW(1UL  (sizeof(size_t) * 4))

  size_t
  fread(void *buf, size_t size, size_t count, FILE *fp)
  {
 -   size_t resid;
 -   char *p;
 -   int r;
 +   size_t desired_total;
 size_t total;
 +   char *dst;

 /*
 -* Extension:  Catch integer overflow
 +* Extension:  Catch integer overflow.
  */
 if ((size = MUL_NO_OVERFLOW || count = MUL_NO_OVERFLOW) 
 size  0  SIZE_MAX / size  count) {
 @@ -57,47 +58,79 @@ fread(void *buf, size_t size, size_t cou
 return (0);
 }

 +   desired_total = count * size;
 +   total = desired_total;
 +
 /*
  * ANSI and SUSv2 require a return value of 0 if size or count are 0.
  */
 -   if ((resid = count * size) == 0)
 +   if (total == 0)
 return (0);
 +
 FLOCKFILE(fp);
 _SET_ORIENTATION(fp, -1);
 +
 +   /* XXX: how can this ever happen?! */
 if (fp-_r  0)
 fp-_r = 0;
 -   total = resid;
 -   p = buf;

 -   if ((fp-_flags  __SNBF) != 0) {
 +
 +   /*
 +* Ensure _bf._size is valid.
 +*/
 +   if (fp-_bf._base == NULL)
 +   __smakebuf(fp);
 +
 +   dst = buf;
 +
 +   while (total  0) {
 /*
 -* We know if we're unbuffered that our buffer is empty, so
 -* we can just read directly. This is much faster than the
 -* loop below which will perform a series of one byte reads.
 +* Copy data out of the buffer.
  */
 -   while (resid  0  (r = (*fp-_read)(fp-_cookie, p, 
 resid))  0) {
 -   p += r;
 -   resid -= r;
 -   }
 -   FUNLOCKFILE(fp);
 -   return ((total - resid) / size);
 +   size_t buffered_bytes = MINIMUM(fp-_r, total);
 +
 +   memcpy(dst, fp-_p, buffered_bytes);
 +   fp-_p += buffered_bytes;
 +   fp-_r -= buffered_bytes;
 +   dst += buffered_bytes;
 +   total -= buffered_bytes;
 +
 +   /*
 +* Are we done?
 +*/
 +   if (total == 0)
 +   goto out;
 +
 +   /*
 +* Do we have so much more to read that we should
 +* avoid copying it through the buffer?
 +*/
 +   if (total  (size_t) fp-_bf._size)
 +   break;
 +
 +   /*
 +* Less than a buffer to go, so refill the buffer and
 +* go around the loop again.
 +*/
 +   if (__srefill(fp))
 +   goto out;
 }

 -   while (resid  (r = fp-_r)) {
 -   (void)memcpy((void *)p, (void *)fp-_p, (size_t)r);
 -   fp-_p += r;
 -   /* fp-_r = 0 ... done in __srefill */
 -   p += r;
 -   resid -= r;
 -   if (__srefill(fp)) {
 -   /* no more input: return partial result */
 -   FUNLOCKFILE(fp);
 -   return ((total - resid) / size);
 +   /*
 +* Read directly into the caller's buffer.
 +*/
 +   while (total  0) {
 +   ssize_t bytes_read = 

Re: amd64 kernel W^X

2015-01-13 Thread Loganaden Velvindron
On Jan 14, 2015 7:57 AM, Theo de Raadt dera...@cvs.openbsd.org wrote:

 Mike Larkin has been slow at informing the world, despite my prodding.
 Probably started working on something else cool...

 So.. I am going to take it upon myself to sing praise to him, and
 hopefully he'll let me off lightly!

 Over the last two months Mike modified the amd64 kernel to follow the
 W^X principles.  It started as a humble exercise to fix the .rodata
 segment, and kind of went crazy.  As a result, no part of the kernel
 address space is writeable and executable simultaneously.  At least
 that is the idea, modulo mistakes.  Final attention to detail (which
 some of you experienced in buggy drafts in snapshots) was to make the
 MP and ACPI trampolines follow W^X, furthermore they are unmapped when
 not required.

 Some further amd64-specific page attribute improvements snuck in.  Too
 complicated to describe simply.

 I followed along for the ride and improved the situation on other
 architectures, mostly MI improvements so the right requests would be
 made to the MD layers.  Final picture is many architectures were
 improved, but amd64 and sparc64 look the best due to MMU features
 available to service the W^X model.  The entire safety model is also
 improved by a limited form of kernel ASLR (the code segment does not
 move around yet, but data and page table ASLR is fairly good.  There
 are some known pages, but hopefully fewer in the future).


That's an amazing feat ! Well done Mike !!


Re: Shadow TCP stacks

2014-10-25 Thread Loganaden Velvindron
On Sat, Oct 25, 2014 at 01:23:47PM -0400, Ian Grant wrote:
  And when you have more than words, please put it on a a
  web site and do nothing more than tell people once.
 
 Still a lot of words, but code too, and an outline of a test framework
 that others may be interested in using. I would be happy to take into
 account any other ideas people might have about what to include in the
 test framework to make it useful for others. Anyone who has comments
 please don't cc this list, post them on the blog if you want them to
 be publicly available.
 
  http://livelogic.blogspot.com/2014/10/shadow-tcp-stacks-in-openbsd.html
 
 Ian
 

Hi Ian,

I think that you're approaching the OpenBSD developer community in a wrong
way.

All diffs should be posted inline on tech@.

You cannot expect the OpenBSD developers to discuss ideas on your blog,
when tech@ is available.

Please note that big intrusive changes are hard to push around if you're
still a newcomer on the list.

I would advise you to send (correct) fixes if you encounter them while going
through existing source code.



Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Loganaden Velvindron
On Wed, Jul 23, 2014 at 10:20:23AM +0200, Hanno B?ck wrote:
 Hi,
 
 Quick background: Some router firmwares from F5 have a bug that they
 fail if the SSL handshake is between 256 and 511 bytes.

F5 should issue fixes for their firmware.

 
 Following up that openssl and other major ssl implementations
 introduced a TLS padding extension that does nothing else than padding
 the handshake if it is between these sizes.
 
 IMHO this is the wrong way of doing things, because it hides bugs
 instead of fixing them. And a bunch of alike workarounds in the past
 are one of the reasons TLS is such a mess these days.
 Also, there have already been devices found that break with this
 workaround because they fail if the ssl handshake is above 512 bytes
 [3].
 
 openssl unconditionally enables the padding extension. I propose a
 simple step: Just remove it from libressl.
 
 
 
 [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
 [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
 [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html
 
 cu,
 -- 
 Hanno B?ck
 http://hboeck.de/
 
 mail/jabber: ha...@hboeck.de
 GPG: BBB51E42

 diff -Naur libressl-2.0.3/include/openssl/tls1.h 
 libressl-2.0.3-1/include/openssl/tls1.h
 --- libressl-2.0.3/include/openssl/tls1.h 2014-07-11 18:50:56.0 
 +0200
 +++ libressl-2.0.3-1/include/openssl/tls1.h   2014-07-23 10:12:34.081669530 
 +0200
 @@ -230,12 +230,6 @@
  /* ExtensionType value from RFC5620 */
  #define TLSEXT_TYPE_heartbeat15
  
 -/* ExtensionType value for TLS padding extension.
 - * 
 http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
 - * http://tools.ietf.org/html/draft-agl-tls-padding-03
 - */
 -#define TLSEXT_TYPE_padding  21
 -
  /* ExtensionType value from RFC4507 */
  #define TLSEXT_TYPE_session_ticket   35
  
 diff -Naur libressl-2.0.3/ssl/t1_lib.c libressl-2.0.3-1/ssl/t1_lib.c
 --- libressl-2.0.3/ssl/t1_lib.c   2014-07-14 01:04:03.0 +0200
 +++ libressl-2.0.3-1/ssl/t1_lib.c 2014-07-23 10:12:13.006933000 +0200
 @@ -635,35 +635,6 @@
   }
  #endif
  
 -#ifdef TLSEXT_TYPE_padding
 - /* Add padding to workaround bugs in F5 terminators.
 -  * See https://tools.ietf.org/html/draft-agl-tls-padding-03
 -  *
 -  * NB: because this code works out the length of all existing
 -  * extensions it MUST always appear last.
 -  */
 - {
 - int hlen = ret - (unsigned char *)s-init_buf-data;
 - /* The code in s23_clnt.c to build ClientHello messages includes the
 -  * 5-byte record header in the buffer, while the code in s3_clnt.c does
 -  * not. */
 - if (s-state == SSL23_ST_CW_CLNT_HELLO_A)
 - hlen -= 5;
 - if (hlen  0xff  hlen  0x200) {
 - hlen = 0x200 - hlen;
 - if (hlen = 4)
 - hlen -= 4;
 - else
 - hlen = 0;
 -
 - s2n(TLSEXT_TYPE_padding, ret);
 - s2n(hlen, ret);
 - memset(ret, 0, hlen);
 - ret += hlen;
 - }
 - }
 -#endif
 -
   if ((extdatalen = ret - p - 2) == 0)
   return p;
  



libressl compilation issues (?)

2014-06-08 Thread Loganaden Velvindron
Hey guys,

I downloaded the latest snapshot, and attempted to build from sources.

However, i'm getting those errors:
/usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c: In function 
'ssl_fill_hello_random':
/usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: 
'SSL_MODE_SEND_SERVERHELLO_TIME' undeclared (first use in this function)
/usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: (Each 
undeclared identifier is reported only once
/usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:300: error: for each 
function it appears in.)
/usr/src/lib/libssl/ssl/../../libssl/src/ssl/s23_clnt.c:302: error: 
'SSL_MODE_SEND_CLIENTHELLO_TIME' undeclared (first use in this function)
*** Error 1 in ssl (bsd.lib.mk:40 's23_clnt.o': @cc -O2 -pipe -g -Wall 
-Werror -DLIBRESSL_INTERNAL -DTERMIOS -DANSI_SOURCE -DOPENSSL_NO_RC...)
*** Error 1 in /usr/src/lib/libssl (bsd.subdir.mk:48 'all'

Am I the only one ?



Re: Typo in macro name for ASN

2014-06-08 Thread Loganaden Velvindron
On Fri, Jun 06, 2014 at 09:47:03AM +0200, Miod Vallat wrote:
 From Quanah Gibson-Mount:
 UNKOWN-UNKNOWN
 
 
 Index: crypto/asn1/asn1_err.c
 
 Please refrain from sending diffs you obviously didn't test.
 
 Miod

Compiled and tested:

Index: src/crypto/asn1/asn1.h
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1.h,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 asn1.h
--- src/crypto/asn1/asn1.h  29 May 2014 20:21:22 -  1.27
+++ src/crypto/asn1/asn1.h  8 Jun 2014 19:40:00 -
@@ -1338,7 +1338,7 @@ void ERR_load_ASN1_strings(void);
 #define ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE  163
 #define ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM  199
 #define ASN1_R_UNKNOWN_TAG  194
-#define ASN1_R_UNKOWN_FORMAT195
+#define ASN1_R_UNKNOWN_FORMAT   195
 #define ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE  164
 #define ASN1_R_UNSUPPORTED_CIPHER   165
 #define ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM 166
Index: src/crypto/asn1/asn1_gen.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1_gen.c,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 asn1_gen.c
--- src/crypto/asn1/asn1_gen.c  30 May 2014 06:22:57 -  1.9
+++ src/crypto/asn1/asn1_gen.c  8 Jun 2014 19:40:00 -
@@ -355,7 +355,7 @@ asn1_cb(const char *elem, int len, void 
else if (!strncmp(vstart, BITLIST, 7))
arg-format = ASN1_GEN_FORMAT_BITLIST;
else {
-   ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKOWN_FORMAT);
+   ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKNOWN_FORMAT);
return -1;
}
break;
Index: src/crypto/asn1/asn1_err.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1_err.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 asn1_err.c
--- src/crypto/asn1/asn1_err.c  19 Apr 2014 10:54:26 -  1.16
+++ src/crypto/asn1/asn1_err.c  8 Jun 2014 19:40:01 -
@@ -303,7 +303,7 @@ static ERR_STRING_DATA ASN1_str_reasons[
{ERR_REASON(ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE), unknown public key type},
{ERR_REASON(ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM), unknown signature 
algorithm},
{ERR_REASON(ASN1_R_UNKNOWN_TAG)  , unknown tag},
-   {ERR_REASON(ASN1_R_UNKOWN_FORMAT), unknown format},
+   {ERR_REASON(ASN1_R_UNKNOWN_FORMAT), unknown format},
{ERR_REASON(ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE), unsupported any 
defined by type},
{ERR_REASON(ASN1_R_UNSUPPORTED_CIPHER)   , unsupported cipher},
{ERR_REASON(ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM), unsupported 
encryption algorithm},



Typo in macro name for ASN

2014-06-06 Thread Loganaden Velvindron
Hi All,

From Quanah Gibson-Mount:
UNKOWN-UNKNOWN


Index: crypto/asn1/asn1_err.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1_err.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 asn1_err.c
--- crypto/asn1/asn1_err.c  19 Apr 2014 10:54:26 -  1.16
+++ crypto/asn1/asn1_err.c  6 Jun 2014 07:35:25 -
@@ -303,7 +303,7 @@ static ERR_STRING_DATA ASN1_str_reasons[
{ERR_REASON(ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE), unknown public key type},
{ERR_REASON(ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM), unknown signature 
algorithm},
{ERR_REASON(ASN1_R_UNKNOWN_TAG)  , unknown tag},
-   {ERR_REASON(ASN1_R_UNKOWN_FORMAT), unknown format},
+   {ERR_REASON(ASN1_R_UNKNOWN_FORMAT), unknown format},
{ERR_REASON(ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE), unsupported any 
defined by type},
{ERR_REASON(ASN1_R_UNSUPPORTED_CIPHER)   , unsupported cipher},
{ERR_REASON(ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM), unsupported 
encryption algorithm},
 



LibreSSL memory leak fix

2014-06-04 Thread Loganaden Velvindron
Hi All,

From OpenSSL RT:
http://rt.openssl.org/Ticket/Display.html?id=3278user=guestpass=guest

len can be 0 as well, and in which case, memory isn't freed. 


Patch from Frantisek Boranek:

Index: lib/libssl/src/crypto/pkcs12/p12_kiss.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/pkcs12/p12_kiss.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 p12_kiss.c
--- lib/libssl/src/crypto/pkcs12/p12_kiss.c 17 Apr 2014 13:37:49 -  
1.12
+++ lib/libssl/src/crypto/pkcs12/p12_kiss.c 4 Jun 2014 09:08:37 -
@@ -269,7 +269,7 @@ static int parse_bag(PKCS12_SAFEBAG *bag
int len, r;
unsigned char *data;
len = ASN1_STRING_to_UTF8(data, fname);
-   if(len  0) {
+   if(len = 0) {
r = X509_alias_set1(x509, data, len);
free(data);
if (!r)



LibreSSL memory leak fix

2014-06-02 Thread Loganaden Velvindron
Hi All,

From Martin Brejcha:



Index: src/lib/libssl/src/crypto/bio/bss_dgram.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bio/bss_dgram.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 bss_dgram.c
--- src/lib/libssl/src/crypto/bio/bss_dgram.c   27 Apr 2014 20:26:48 -  
1.25
+++ src/lib/libssl/src/crypto/bio/bss_dgram.c   2 Jun 2014 07:20:34 -
@@ -1224,6 +1224,7 @@ dgram_sctp_ctrl(BIO *b, int cmd, long nu
memcpy(authkey-sca_key[0], ptr, 64 * sizeof(uint8_t));
 
ret = setsockopt(b-num, IPPROTO_SCTP, SCTP_AUTH_KEY, authkey, 
sockopt_len);
+   free(authkey);
if (ret  0)
break;
 



spelling correction for libressl verify.pod

2014-05-25 Thread Loganaden Velvindron
Hi All,

From OpenSSL RT 3355:

Index: doc/apps/verify.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/apps/verify.pod,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 verify.pod
--- doc/apps/verify.pod 4 May 2014 20:31:33 -   1.8
+++ doc/apps/verify.pod 25 May 2014 06:35:15 -
@@ -385,7 +385,7 @@ an application specific error. Unused.
 
 =head1 BUGS
 
-Although the issuer checks are a considerably improvement over the old 
technique they still
+Although the issuer checks are a considerable improvement over the old 
technique they still
 suffer from limitations in the underlying X509_LOOKUP API. One consequence of 
this is that
 trusted certificates with matching subject name must either appear in a file 
(as specified by the
 B-CAfile option) or a directory (as specified by B-CApath. If they occur 
in both then only



-noout description in sess_id.c

2014-05-25 Thread Loganaden Velvindron
Hi All,

From Martin Kaiser (OpenSSL RT #3364):

-noout mentions a CRL, which is incorrect.

Index: lib/libssl/src/apps/sess_id.c
===
RCS file: /cvs/src/lib/libssl/src/apps/sess_id.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 sess_id.c
--- lib/libssl/src/apps/sess_id.c   23 May 2014 16:10:02 -  1.16
+++ lib/libssl/src/apps/sess_id.c   25 May 2014 06:48:05 -
@@ -77,7 +77,7 @@ static const char *sess_id_usage[] = {
 -out arg- output file - default stdout\n,
 -text   - print ssl session id details\n,
 -cert   - output certificate \n,
--noout  - no CRL output\n,
+-noout  - no output of encoded session info\n,
 -context arg- set the session ID context\n,
NULL
 };



socket descriptor leak in s_socket.c

2014-05-25 Thread Loganaden Velvindron
Hi All,

From OpenSSL RT #3342:


CID: 966576  96677

Index: lib/libssl/src/apps/s_socket.c
===
RCS file: /cvs/src/lib/libssl/src/apps/s_socket.c,v
retrieving revision 1.38
diff -u -p -u -p -r1.38 s_socket.c
--- lib/libssl/src/apps/s_socket.c  23 May 2014 16:16:55 -  1.38
+++ lib/libssl/src/apps/s_socket.c  25 May 2014 07:25:03 -
@@ -122,6 +122,7 @@ init_client(int *sock, char *host, char 
(char *) i, sizeof(i));
if (i  0) {
perror(keepalive);
+   close(s);
return (0);
}
}
@@ -281,16 +282,19 @@ redoit:
} else {
if ((*host = strdup(h1-h_name)) == NULL) {
perror(strdup);
+   close(ret);
return (0);
}
 
h2 = gethostbyname(*host);
if (h2 == NULL) {
BIO_printf(bio_err, gethostbyname failure\n);
+   close(ret);
return (0);
}
if (h2-h_addrtype != AF_INET) {
BIO_printf(bio_err, gethostbyname addr is not 
AF_INET\n);
+   close(ret);
return (0);
}
}



typo in ssl_err.c

2014-05-25 Thread Loganaden Velvindron
Hi All,

From Marcos Marado:

heartbearts-heartbeats.

Index: src/ssl/ssl_err.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/ssl_err.c,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 ssl_err.c
--- src/ssl/ssl_err.c   14 Apr 2014 13:10:35 -  1.19
+++ src/ssl/ssl_err.c   25 May 2014 10:08:32 -
@@ -539,7 +539,7 @@ static ERR_STRING_DATA SSL_str_reasons[]
{ERR_REASON(SSL_R_TLSV1_UNRECOGNIZED_NAME), tlsv1 unrecognized name},
{ERR_REASON(SSL_R_TLSV1_UNSUPPORTED_EXTENSION), tlsv1 unsupported 
extension},
{ERR_REASON(SSL_R_TLS_CLIENT_CERT_REQ_WITH_ANON_CIPHER), tls client 
cert req with anon cipher},
-   {ERR_REASON(SSL_R_TLS_HEARTBEAT_PEER_DOESNT_ACCEPT), peer does not 
accept heartbearts},
+   {ERR_REASON(SSL_R_TLS_HEARTBEAT_PEER_DOESNT_ACCEPT), peer does not 
accept heartbeats},
{ERR_REASON(SSL_R_TLS_HEARTBEAT_PENDING) , heartbeat request already 
pending},
{ERR_REASON(SSL_R_TLS_ILLEGAL_EXPORTER_LABEL), tls illegal exporter 
label},
{ERR_REASON(SSL_R_TLS_INVALID_ECPOINTFORMAT_LIST), tls invalid 
ecpointformat list},



sftp zap extra whitespace

2014-05-04 Thread Loganaden Velvindron
Hi All,

An extra whitespace can be removed here:

Index: sftp.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.162
diff -u -p -u -p -r1.162 sftp.c
--- sftp.c  29 Apr 2014 20:36:51 -  1.162
+++ sftp.c  4 May 2014 09:26:56 -
@@ -707,7 +707,7 @@ process_put(struct sftp_conn *conn, char
 
 resume |= global_aflag;
if (!quiet  resume)
-   printf(Resuming upload of  %s to %s\n, g.gl_pathv[i], 
+   printf(Resuming upload of %s to %s\n, g.gl_pathv[i], 
abs_dst);
else if (!quiet  !resume)
printf(Uploading %s to %s\n, g.gl_pathv[i], abs_dst);



ssh regression suite connect-privsep.sh issue

2014-05-04 Thread Loganaden Velvindron
Hi All,

The 'Z' flag was removed 10 days ago by Ted.

connect-privsep.sh complains that there is an unknown malloc option.

Diff below:

Index: connect-privsep.sh
===
RCS file: /cvs/src/regress/usr.bin/ssh/connect-privsep.sh,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 connect-privsep.sh
--- connect-privsep.sh  2 Jul 2012 14:37:06 -   1.4
+++ connect-privsep.sh  4 May 2014 10:15:50 -
@@ -25,7 +25,7 @@ done
 
 # Because sandbox is sensitive to changes in libc, especially malloc, retest
 # with every malloc.conf option (and none).
-for m in '' A F G H J P R S X Z '' ''; do
+for m in '' A F G H J P R S X '' ''; do
 for p in 1 2; do
env MALLOC_OPTIONS=$m ${SSH} -$p -F $OBJ/ssh_proxy 999.999.999.999 
true
if [ $? -ne 0 ]; then



Re: IPv6 by default

2014-04-28 Thread Loganaden Velvindron
On Tue, Apr 29, 2014 at 2:05 AM, Simon Perreault si...@per.reau.lt wrote:
 Tech,

 Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan:
 make getaddrinfo() return IPv6 results first by default.

 The diff below would be the end goal. I guess people will have valid 
 objections
 to it. I'd like to know what they are.

 Would it be necessary/desirable to check all calls to getaddrinfo() in base 
 and
 add AI_ADDRCONFIG to hints.ai_flags where needed? (i.e. pretty much everywhere
 except special cases which right now I can't think of any)

That seems like a good idea to me :-)



 Thanks,
 Simon


 Index: lib/libc/asr/asr.c
 ===
 RCS file: /cvs/src/lib/libc/asr/asr.c,v
 retrieving revision 1.33
 diff -u -p -r1.33 asr.c
 --- lib/libc/asr/asr.c  26 Mar 2014 18:13:15 -  1.33
 +++ lib/libc/asr/asr.c  28 Apr 2014 21:43:52 -
 @@ -518,8 +518,8 @@ asr_ctx_create(void)
 ac-ac_options = RES_RECURSE | RES_DEFNAMES | RES_DNSRCH;
 ac-ac_refcount = 1;
 ac-ac_ndots = 1;
 -   ac-ac_family[0] = AF_INET;
 -   ac-ac_family[1] = AF_INET6;
 +   ac-ac_family[0] = AF_INET6;
 +   ac-ac_family[1] = AF_INET;
 ac-ac_family[2] = -1;

 ac-ac_hostfile = DEFAULT_HOSTFILE;
 Index: share/man/man5/resolv.conf.5
 ===
 RCS file: /cvs/src/share/man/man5/resolv.conf.5,v
 retrieving revision 1.44
 diff -u -p -r1.44 resolv.conf.5
 --- share/man/man5/resolv.conf.514 Jul 2013 19:44:39 -  1.44
 +++ share/man/man5/resolv.conf.528 Apr 2014 21:43:52 -
 @@ -217,8 +217,8 @@ For example:
  .It Cm family
  Specify which type of Internet protocol family to prefer,
  if a host is reachable using different address families.
 -By default IPv4 addresses are queried first,
 -and then IPv6 addresses.
 +By default IPv6 addresses are queried first,
 +and then IPv4 addresses.
  The syntax is:
  .Bd -ragged -offset indent
  .Cm family Ar family Op Ar family




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: IPv6 DoS sysctl man page additions

2014-04-22 Thread Loganaden Velvindron
On Mon, Apr 21, 2014 at 09:39:55PM -0300, Fernando Gont wrote:
 Hi, Loganaden,
 
 NetBSD really had these? I seem to recall that OpenBSD was the only BSD
 variant with these (sensible) knobs.
 
 Thanks,
 Fernando


They copied it from OpenBSD in 2012:

kernel: Add sysctls to avoid ipv6 DoS attacks (from OpenBSD):
net.inet6.ip6.neighborgcthresh = 2048
net.inet6.ip6.maxifprefixes = 16
net.inet6.ip6.maxifdefrouters = 16
net.inet6.ip6.maxdynroutes = 4096
[christos 20120622]

 
 
 
 On 04/19/2014 08:04 AM, Loganaden Velvindron wrote:
  Hi All,
  
  I'm taking a short break from playing with pf statistics.
  
  There were 4 sysctls added from KAME, but the man pages weren't updated
  accordingly.
  
  (Adapted from the NetBSD man page changes)
  
  Feedback welcomed.
  
  
  Index: lib/libc/gen/sysctl.3
  ===
  RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
  retrieving revision 1.228
  diff -u -p -u -p -r1.228 sysctl.3
  --- lib/libc/gen/sysctl.3   21 Jan 2014 03:15:45 -  1.228
  +++ lib/libc/gen/sysctl.3   19 Apr 2014 10:58:30 -
  @@ -1676,11 +1676,15 @@ The currently defined protocols and name
   .It ip6 Ta hdrnestlimit Ta integer Ta yes
   .It ip6 Ta hlim Ta integer Ta yes
   .It ip6 Ta log_interval Ta integer Ta yes
  +.It ip6 Ta maxdynroutes Ta integer Ta yes
   .It ip6 Ta maxfragpackets Ta integer Ta yes
   .It ip6 Ta maxfrags Ta integer Ta yes
  +.It ip6 Ta maxifprefixes Ta integer Ta yes
  +.It ip6 Ta maxifdefrouters Ta integer Ta yes
   .It ip6 Ta mforwarding Ta integer Ta yes
   .It ip6 Ta multicast_mtudisc Ta integer Ta yes
   .It ip6 Ta multipath Ta integer Ta yes
  +.It ip6 Ta neighborgcthresh Ta integer Ta yes
   .It ip6 Ta redirect Ta integer Ta yes
   .It ip6 Ta rr_prune Ta integer Ta yes
   .It ip6 Ta use_deprecated Ta integer Ta yes
  @@ -1834,6 +1838,11 @@ IPv6 packet forwarding engine.
   The value indicates the number of
   seconds of interval which must elapse between log output.
   .Pp
  +.It Li ip6.maxdynroutes 
  +Maximum number of routes created by redirect. 
  +Set it to negative to disable. 
  +The default value is 4096. 
  +.Pp
   .It Li ip6.maxfragpackets
   The maximum number of fragmented packets the node will accept.
   0 means that the node will not accept any fragmented packets.
  @@ -1846,6 +1855,17 @@ The maximum number of fragments the node
   \-1 means that the node will accept as many fragments as it receives.
   The flag is provided basically for avoiding possible DoS attacks.
   .Pp
  +.It Li ip6.maxifprefixes
  +Maximum number of prefixes created by route advertisements per interface.
  +Set it to negative to disable.
  +The default value is 16.
  +.Pp
  +.It Li ip6.maxifdefrouters 16
  +Maximum number of default routers created by route advertisements per
  +interface.
  +Set it to negative to disable.
  +The default value is 16.
  +.Pp
   .It Li ip6.mforwarding
   If set to 1, then multicast forwarding is enabled for the host.
   The default is 0.
  @@ -1861,6 +1881,11 @@ If set to 0, the ICMPv6 Too Big message 
   This variable enables multipath routing for IPv6 addresses.
   If set to 0, only the first route selected will be used for a given
   destination regardless of how many routes exist in the routing table.
  +.Pp
  +.It Li ip6.neighborgcthresh
  +Maximum number of entries in neighbor cache.
  +Set to negative to disable.
  +The default value is 2048.
   .Pp
   .It Li ip6.redirect
   Returns 1 when ICMPv6 redirects may be sent by the node.
  Index: sbin/sysctl/sysctl.8
  ===
  RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
  retrieving revision 1.173
  diff -u -p -u -p -r1.173 sysctl.8
  --- sbin/sysctl/sysctl.828 Oct 2013 21:02:35 -  1.173
  +++ sbin/sysctl/sysctl.819 Apr 2014 10:58:30 -
  @@ -301,10 +301,14 @@ and a few require a kernel compiled with
   .It net.inet6.ip6.use_deprecated Ta integer Ta yes
   .It net.inet6.ip6.rr_prune Ta integer Ta yes
   .It net.inet6.ip6.v6only Ta integer Ta no
  +.It net.inet6.ip6.maxdynroutes Ta integer Ta yes
   .It net.inet6.ip6.maxfrags Ta integer Ta yes
  +.It net.inet6.ip6.maxifprefixes Ta integer Ta yes
  +.It net.inet6.ip6.maxifdefrouters Ta integer Ta yes
   .It net.inet6.ip6.mforwarding Ta integer Ta yes
   .It net.inet6.ip6.multipath Ta integer Ta yes
   .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
  +.It net.inet6.ip6.neighborgcthresh Ta integer Ta yes
   .It net.inet6.icmp6.rediraccept Ta integer Ta yes
   .It net.inet6.icmp6.redirtimeout Ta integer Ta yes
   .It net.inet6.icmp6.nd6_prune Ta integer Ta yes
  
  
 
 
 -- 
 Fernando Gont
 e-mail: ferna...@gont.com.ar || fg...@si6networks.com
 PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
 
 
 



sftp enum alphabetical sort fix

2014-04-21 Thread Loganaden Velvindron
Hi All,

Trivial fix for sftp.

Index: sftp.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.159
diff -u -p -u -p -r1.159 sftp.c
--- sftp.c  21 Apr 2014 14:36:16 -  1.159
+++ sftp.c  21 Apr 2014 14:50:10 -
@@ -130,15 +130,15 @@ enum sftp_command {
I_PUT,
I_PWD,
I_QUIT,
+   I_REGET,
I_RENAME,
+   I_REPUT,
I_RM,
I_RMDIR,
I_SHELL,
I_SYMLINK,
I_VERSION,
I_PROGRESS,
-   I_REGET,
-   I_REPUT
 };
 
 struct CMD {



Re: [Patch] security: check ed25519 private key

2014-04-21 Thread Loganaden Velvindron
On Mon, Apr 21, 2014 at 04:20:03PM +0200, Fritjof Bornebusch wrote:
 Hi tech@,
 
 here is a small diff, that checks if the ~/.ssh/id_ed25519 private key has 
 the right permissions.

That's seems good to me.


 
 Fritjof
 
 Index: security
 ===
 RCS file: /cvs/src/libexec/security/security,v
 retrieving revision 1.24
 diff -u -p -r1.24 security
 --- security23 Mar 2014 22:08:15 -  1.24
 +++ security20 Apr 2014 22:41:57 -
 @@ -387,7 +387,7 @@ sub check_dot_readable {
 foreach my $f (qw(
 .netrc .rhosts .gnupg/secring.gpg .gnupg/random_seed
 .pgp/secring.pgp .shosts .ssh/identity .ssh/id_dsa .ssh/id_ecdsa
 -   .ssh/id_rsa 
 +   .ssh/id_rsa .ssh/id_ed25519
 )) {
 next unless -e $home/$f;
 my ($mode, $fuid) = (stat(_))[2,4];
 



sftp upload resume support man page diff

2014-04-21 Thread Loganaden Velvindron
Hi All,

As sftp resume upload has been implemented, here's a man page diff
to describe the feature.

Feedback welcomed.

Index: sftp.1
===
RCS file: /cvs/src/usr.bin/ssh/sftp.1,v
retrieving revision 1.97
diff -u -p -u -p -r1.97 sftp.1
--- sftp.1  20 Oct 2013 09:51:26 -  1.97
+++ sftp.1  21 Apr 2014 16:28:22 -
@@ -108,9 +108,10 @@ Forces
 .Nm
 to use IPv6 addresses only.
 .It Fl a
-Attempt to continue interrupted downloads rather than overwriting existing
-partial or complete copies of files.
-If the remote file contents differ from the partial local copy then the
+Attempt to continue interrupted downloads or uploads rather than overwriting 
+existing partial or complete copies of files.
+If the remote file contents differ from the partial local copy or the
+inverse, then the
 resultant file is likely to be corrupt.
 .It Fl B Ar buffer_size
 Specify the size of the buffer that
@@ -134,7 +135,7 @@ may be used to indicate standard input.
 .Nm
 will abort if any of the following
 commands fail:
-.Ic get , put , reget , rename , ln ,
+.Ic get , put , reput, reget , rename , ln ,
 .Ic rm , mkdir , chdir , ls ,
 .Ic lchdir , chmod , chown ,
 .Ic chgrp , lpwd , df , symlink ,
@@ -495,7 +496,7 @@ Create remote directory specified by
 .It Ic progress
 Toggle display of progress meter.
 .It Xo Ic put
-.Op Fl fPpr
+.Op Fl afPpr
 .Ar local-path
 .Op Ar remote-path
 .Xc
@@ -514,6 +515,13 @@ is specified, then
 .Ar remote-path
 must specify a directory.
 .Pp
+If the .Fl a
+flag is specified, then attempt to resume partial
+transfers of existing files.  Note that resumption assumes that
+any partial copy of the remote file matches the local copy.  If
+the local file contents differ from the remote local copy then
+the resultant file is likely to be corrupt.
+.Pp
 If the
 .Fl f
 flag is specified, then a request will be sent to the server to call
@@ -540,6 +548,18 @@ Display remote working directory.
 .It Ic quit
 Quit
 .Nm sftp .
+.It Xo Ic reput
+.Op Fl Ppr
+.Op Ar local-path
+.Ar remote-path
+.Xc
+Resume upload of
+.Op Ar local-path .
+Equivalent to
+.Ic put
+with the
+.Fl a
+flag set.
 .It Xo Ic reget
 .Op Fl Ppr
 .Ar remote-path



Re: sftp upload resume diff

2014-04-20 Thread Loganaden Velvindron
Simplify the diff:

use -a for both upload and download resume support. 
This makes it more consistent.

Index: sftp-client.h
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.h,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 sftp-client.h
--- sftp-client.h   17 Oct 2013 00:30:13 -  1.24
+++ sftp-client.h   20 Apr 2014 12:00:47 -
@@ -120,13 +120,13 @@ int download_dir(struct sftp_conn *, cha
  * Upload 'local_path' to 'remote_path'. Preserve permissions and times
  * if 'pflag' is set
  */
-int do_upload(struct sftp_conn *, char *, char *, int, int);
+int do_upload(struct sftp_conn *, char *, char *, int, int, int);
 
 /*
  * Recursively upload 'local_directory' to 'remote_directory'. Preserve 
  * times if 'pflag' is set
  */
-int upload_dir(struct sftp_conn *, char *, char *, int, int, int);
+int upload_dir(struct sftp_conn *, char *, char *, int, int, int, int);
 
 /* Concatenate paths, taking care of slashes. Caller must free result. */
 char *path_append(char *, char *);
Index: sftp-client.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v
retrieving revision 1.114
diff -u -p -u -p -r1.114 sftp-client.c
--- sftp-client.c   31 Jan 2014 16:39:19 -  1.114
+++ sftp-client.c   20 Apr 2014 12:00:47 -
@@ -1409,7 +1409,7 @@ download_dir(struct sftp_conn *conn, cha
 
 int
 do_upload(struct sftp_conn *conn, char *local_path, char *remote_path,
-int preserve_flag, int fsync_flag)
+int preserve_flag, int resume, int fsync_flag)
 {
int local_fd;
int status = SSH2_FX_OK;
@@ -1418,7 +1418,7 @@ do_upload(struct sftp_conn *conn, char *
char *handle, *data;
Buffer msg;
struct stat sb;
-   Attrib a;
+   Attrib a, *c = NULL;
u_int32_t startid;
u_int32_t ackid;
struct outstanding_ack {
@@ -1456,6 +1456,26 @@ do_upload(struct sftp_conn *conn, char *
if (!preserve_flag)
a.flags = ~SSH2_FILEXFER_ATTR_ACMODTIME;
 
+   if (resume) {
+   /* Get remote file size if it exists */
+   if ((c = do_stat(conn, remote_path, 0)) == NULL) {
+   close(local_fd);
+   return -1;
+   }
+
+   if ((off_t)c-size = sb.st_size) {
+   error(destination file bigger or same size as 
+ source file);
+   close(local_fd);
+   return -1;
+   }
+
+   if (lseek(local_fd, (off_t)c-size, SEEK_SET) == -1) {
+   close(local_fd);
+   return -1;
+   }
+   }
+
buffer_init(msg);
 
/* Send open request */
@@ -1463,7 +1483,8 @@ do_upload(struct sftp_conn *conn, char *
buffer_put_char(msg, SSH2_FXP_OPEN);
buffer_put_int(msg, id);
buffer_put_cstring(msg, remote_path);
-   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|SSH2_FXF_TRUNC);
+   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|
+ (resume ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC));
encode_attrib(msg, a);
send_msg(conn, msg);
debug3(Sent message SSH2_FXP_OPEN I:%u P:%s, id, remote_path);
@@ -1482,7 +1503,7 @@ do_upload(struct sftp_conn *conn, char *
data = xmalloc(conn-transfer_buflen);
 
/* Read from local and write to remote */
-   offset = progress_counter = 0;
+   offset = progress_counter = (resume ? c-size : 0);
if (showprogress)
start_progress_meter(local_path, sb.st_size,
progress_counter);
@@ -1596,7 +1617,7 @@ do_upload(struct sftp_conn *conn, char *
 
 static int
 upload_dir_internal(struct sftp_conn *conn, char *src, char *dst, int depth,
-int preserve_flag, int print_flag, int fsync_flag)
+int preserve_flag, int print_flag, int resume, int fsync_flag)
 {
int ret = 0, status;
DIR *dirp;
@@ -1665,12 +1686,12 @@ upload_dir_internal(struct sftp_conn *co
continue;
 
if (upload_dir_internal(conn, new_src, new_dst,
-   depth + 1, preserve_flag, print_flag,
+   depth + 1, preserve_flag, print_flag, resume,
fsync_flag) == -1)
ret = -1;
} else if (S_ISREG(sb.st_mode)) {
if (do_upload(conn, new_src, new_dst,
-   preserve_flag, fsync_flag) == -1) {
+   preserve_flag, resume, fsync_flag) == -1) {
error(Uploading of file %s to %s failed!,
new_src, new_dst);
ret = -1;
@@ -1689,7 +1710,7 @@ upload_dir_internal(struct sftp_conn *co
 
 int
 

IPv6 DoS sysctl man page additions

2014-04-19 Thread Loganaden Velvindron
Hi All,

I'm taking a short break from playing with pf statistics.

There were 4 sysctls added from KAME, but the man pages weren't updated
accordingly.

(Adapted from the NetBSD man page changes)

Feedback welcomed.


Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.228
diff -u -p -u -p -r1.228 sysctl.3
--- lib/libc/gen/sysctl.3   21 Jan 2014 03:15:45 -  1.228
+++ lib/libc/gen/sysctl.3   19 Apr 2014 10:58:30 -
@@ -1676,11 +1676,15 @@ The currently defined protocols and name
 .It ip6 Ta hdrnestlimit Ta integer Ta yes
 .It ip6 Ta hlim Ta integer Ta yes
 .It ip6 Ta log_interval Ta integer Ta yes
+.It ip6 Ta maxdynroutes Ta integer Ta yes
 .It ip6 Ta maxfragpackets Ta integer Ta yes
 .It ip6 Ta maxfrags Ta integer Ta yes
+.It ip6 Ta maxifprefixes Ta integer Ta yes
+.It ip6 Ta maxifdefrouters Ta integer Ta yes
 .It ip6 Ta mforwarding Ta integer Ta yes
 .It ip6 Ta multicast_mtudisc Ta integer Ta yes
 .It ip6 Ta multipath Ta integer Ta yes
+.It ip6 Ta neighborgcthresh Ta integer Ta yes
 .It ip6 Ta redirect Ta integer Ta yes
 .It ip6 Ta rr_prune Ta integer Ta yes
 .It ip6 Ta use_deprecated Ta integer Ta yes
@@ -1834,6 +1838,11 @@ IPv6 packet forwarding engine.
 The value indicates the number of
 seconds of interval which must elapse between log output.
 .Pp
+.It Li ip6.maxdynroutes 
+Maximum number of routes created by redirect. 
+Set it to negative to disable. 
+The default value is 4096. 
+.Pp
 .It Li ip6.maxfragpackets
 The maximum number of fragmented packets the node will accept.
 0 means that the node will not accept any fragmented packets.
@@ -1846,6 +1855,17 @@ The maximum number of fragments the node
 \-1 means that the node will accept as many fragments as it receives.
 The flag is provided basically for avoiding possible DoS attacks.
 .Pp
+.It Li ip6.maxifprefixes
+Maximum number of prefixes created by route advertisements per interface.
+Set it to negative to disable.
+The default value is 16.
+.Pp
+.It Li ip6.maxifdefrouters 16
+Maximum number of default routers created by route advertisements per
+interface.
+Set it to negative to disable.
+The default value is 16.
+.Pp
 .It Li ip6.mforwarding
 If set to 1, then multicast forwarding is enabled for the host.
 The default is 0.
@@ -1861,6 +1881,11 @@ If set to 0, the ICMPv6 Too Big message 
 This variable enables multipath routing for IPv6 addresses.
 If set to 0, only the first route selected will be used for a given
 destination regardless of how many routes exist in the routing table.
+.Pp
+.It Li ip6.neighborgcthresh
+Maximum number of entries in neighbor cache.
+Set to negative to disable.
+The default value is 2048.
 .Pp
 .It Li ip6.redirect
 Returns 1 when ICMPv6 redirects may be sent by the node.
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.173
diff -u -p -u -p -r1.173 sysctl.8
--- sbin/sysctl/sysctl.828 Oct 2013 21:02:35 -  1.173
+++ sbin/sysctl/sysctl.819 Apr 2014 10:58:30 -
@@ -301,10 +301,14 @@ and a few require a kernel compiled with
 .It net.inet6.ip6.use_deprecated Ta integer Ta yes
 .It net.inet6.ip6.rr_prune Ta integer Ta yes
 .It net.inet6.ip6.v6only Ta integer Ta no
+.It net.inet6.ip6.maxdynroutes Ta integer Ta yes
 .It net.inet6.ip6.maxfrags Ta integer Ta yes
+.It net.inet6.ip6.maxifprefixes Ta integer Ta yes
+.It net.inet6.ip6.maxifdefrouters Ta integer Ta yes
 .It net.inet6.ip6.mforwarding Ta integer Ta yes
 .It net.inet6.ip6.multipath Ta integer Ta yes
 .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
+.It net.inet6.ip6.neighborgcthresh Ta integer Ta yes
 .It net.inet6.icmp6.rediraccept Ta integer Ta yes
 .It net.inet6.icmp6.redirtimeout Ta integer Ta yes
 .It net.inet6.icmp6.nd6_prune Ta integer Ta yes



Re: IPv6 DoS sysctl man page additions

2014-04-19 Thread Loganaden Velvindron
On Sat, Apr 19, 2014 at 04:04:30AM -0700, Loganaden Velvindron wrote:
 Hi All,
 
 I'm taking a short break from playing with pf statistics.
 
 There were 4 sysctls added from KAME, but the man pages weren't updated
 accordingly.
 
 (Adapted from the NetBSD man page changes)
 
 Feedback welcomed.
 
 

Removed trailing spaces and use set to instead of set it to based
on feedback from sthen@


Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.228
diff -u -p -u -p -r1.228 sysctl.3
--- lib/libc/gen/sysctl.3   21 Jan 2014 03:15:45 -  1.228
+++ lib/libc/gen/sysctl.3   19 Apr 2014 11:17:13 -
@@ -1676,11 +1676,15 @@ The currently defined protocols and name
 .It ip6 Ta hdrnestlimit Ta integer Ta yes
 .It ip6 Ta hlim Ta integer Ta yes
 .It ip6 Ta log_interval Ta integer Ta yes
+.It ip6 Ta maxdynroutes Ta integer Ta yes
 .It ip6 Ta maxfragpackets Ta integer Ta yes
 .It ip6 Ta maxfrags Ta integer Ta yes
+.It ip6 Ta maxifprefixes Ta integer Ta yes
+.It ip6 Ta maxifdefrouters Ta integer Ta yes
 .It ip6 Ta mforwarding Ta integer Ta yes
 .It ip6 Ta multicast_mtudisc Ta integer Ta yes
 .It ip6 Ta multipath Ta integer Ta yes
+.It ip6 Ta neighborgcthresh Ta integer Ta yes
 .It ip6 Ta redirect Ta integer Ta yes
 .It ip6 Ta rr_prune Ta integer Ta yes
 .It ip6 Ta use_deprecated Ta integer Ta yes
@@ -1834,6 +1838,11 @@ IPv6 packet forwarding engine.
 The value indicates the number of
 seconds of interval which must elapse between log output.
 .Pp
+.It Li ip6.maxdynroutes
+Maximum number of routes created by redirect.
+Set to negative to disable.
+The default value is 4096.
+.Pp
 .It Li ip6.maxfragpackets
 The maximum number of fragmented packets the node will accept.
 0 means that the node will not accept any fragmented packets.
@@ -1846,6 +1855,17 @@ The maximum number of fragments the node
 \-1 means that the node will accept as many fragments as it receives.
 The flag is provided basically for avoiding possible DoS attacks.
 .Pp
+.It Li ip6.maxifprefixes
+Maximum number of prefixes created by route advertisements per interface.
+Set to negative to disable.
+The default value is 16.
+.Pp
+.It Li ip6.maxifdefrouters 16
+Maximum number of default routers created by route advertisements per
+interface.
+Set to negative to disable.
+The default value is 16.
+.Pp
 .It Li ip6.mforwarding
 If set to 1, then multicast forwarding is enabled for the host.
 The default is 0.
@@ -1861,6 +1881,11 @@ If set to 0, the ICMPv6 Too Big message 
 This variable enables multipath routing for IPv6 addresses.
 If set to 0, only the first route selected will be used for a given
 destination regardless of how many routes exist in the routing table.
+.Pp
+.It Li ip6.neighborgcthresh
+Maximum number of entries in neighbor cache.
+Set to negative to disable.
+The default value is 2048.
 .Pp
 .It Li ip6.redirect
 Returns 1 when ICMPv6 redirects may be sent by the node.
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.173
diff -u -p -u -p -r1.173 sysctl.8
--- sbin/sysctl/sysctl.828 Oct 2013 21:02:35 -  1.173
+++ sbin/sysctl/sysctl.819 Apr 2014 11:17:15 -
@@ -301,10 +301,14 @@ and a few require a kernel compiled with
 .It net.inet6.ip6.use_deprecated Ta integer Ta yes
 .It net.inet6.ip6.rr_prune Ta integer Ta yes
 .It net.inet6.ip6.v6only Ta integer Ta no
+.It net.inet6.ip6.maxdynroutes Ta integer Ta yes
 .It net.inet6.ip6.maxfrags Ta integer Ta yes
+.It net.inet6.ip6.maxifprefixes Ta integer Ta yes
+.It net.inet6.ip6.maxifdefrouters Ta integer Ta yes
 .It net.inet6.ip6.mforwarding Ta integer Ta yes
 .It net.inet6.ip6.multipath Ta integer Ta yes
 .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
+.It net.inet6.ip6.neighborgcthresh Ta integer Ta yes
 .It net.inet6.icmp6.rediraccept Ta integer Ta yes
 .It net.inet6.icmp6.redirtimeout Ta integer Ta yes
 .It net.inet6.icmp6.nd6_prune Ta integer Ta yes



IPv6 mtudisctimeout sysctl man page fix

2014-04-19 Thread Loganaden Velvindron
Hi All,

The code was added for MTU discovery timeout in IPv6, but the man 
page misses the description.

Feedback welcomed.


Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.174
diff -u -p -u -p -r1.174 sysctl.8
--- sbin/sysctl/sysctl.819 Apr 2014 12:42:50 -  1.174
+++ sbin/sysctl/sysctl.819 Apr 2014 14:46:11 -
@@ -319,6 +319,7 @@ and a few require a kernel compiled with
 .It net.inet6.icmp6.nodeinfo Ta integer Ta yes
 .It net.inet6.icmp6.errppslimit Ta integer Ta yes
 .It net.inet6.icmp6.nd6_maxnudhint Ta integer Ta yes
+.It net.inet6.icmp6.mtudisctimeout Ta integer Ta yes
 .It net.inet6.icmp6.mtudisc_hiwat Ta integer Ta yes
 .It net.inet6.icmp6.mtudisc_lowat Ta integer Ta yes
 .It net.inet6.icmp6.nd6_debug Ta integer Ta yes
Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.229
diff -u -p -u -p -r1.229 sysctl.3
--- lib/libc/gen/sysctl.3   19 Apr 2014 12:42:50 -  1.229
+++ lib/libc/gen/sysctl.3   19 Apr 2014 14:46:12 -
@@ -1656,6 +1656,7 @@ The currently defined protocols and name
 .Bl -column Protocol name multicast_mtudisc integer yes -offset indent
 .It Sy Protocol name Ta Sy Variable name Ta Sy Type Ta Sy Changeable
 .It icmp6 Ta errppslimit Ta integer Ta yes
+.It icmp6 Ta mtudisctimeout Ta integer Ta yes
 .It icmp6 Ta mtudisc_hiwat Ta integer Ta yes
 .It icmp6 Ta mtudisc_lowat Ta integer Ta yes
 .It icmp6 Ta nd6_debug Ta integer Ta yes
@@ -1700,6 +1701,10 @@ per second.
 ICMPv6 error messages exceeding this value are subject to rate limitation
 and will not go out from the node.
 A negative value will disable the rate limitation.
+.Pp
+.It Li icmp6.mtudisctimeout
+Returns the number of seconds in which a route added by the Path MTU
+Discovery engine will time out.
 .Pp
 .It Li icmp6.mtudisc_hiwat
 .It Li icmp6.mtudisc_lowat



Re: IPv6 mtudisctimeout sysctl man page fix

2014-04-19 Thread Loganaden Velvindron
On Sat, Apr 19, 2014 at 07:51:34AM -0700, Loganaden Velvindron wrote:
 Hi All,
 
 The code was added for MTU discovery timeout in IPv6, but the man 
 page misses the description.
 
 Feedback welcomed.
 
 

s/icmp6/ip6 from henning@ and sthen@, and change from Return the number of
seconds to Number of Seconds for both IPv4 and IPv6.

Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.174
diff -u -p -u -p -r1.174 sysctl.8
--- sbin/sysctl/sysctl.819 Apr 2014 12:42:50 -  1.174
+++ sbin/sysctl/sysctl.819 Apr 2014 15:14:39 -
@@ -306,6 +306,7 @@ and a few require a kernel compiled with
 .It net.inet6.ip6.maxifprefixes Ta integer Ta yes
 .It net.inet6.ip6.maxifdefrouters Ta integer Ta yes
 .It net.inet6.ip6.mforwarding Ta integer Ta yes
+.It net.inet6.ip6.mtudisctimeout Ta integer Ta yes
 .It net.inet6.ip6.multipath Ta integer Ta yes
 .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
 .It net.inet6.ip6.neighborgcthresh Ta integer Ta yes
Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.229
diff -u -p -u -p -r1.229 sysctl.3
--- lib/libc/gen/sysctl.3   19 Apr 2014 12:42:50 -  1.229
+++ lib/libc/gen/sysctl.3   19 Apr 2014 15:14:42 -
@@ -1476,7 +1476,7 @@ The default is 0.
 .It Li ip.mtudisc
 Returns 1 if Path MTU Discovery is enabled.
 .It Li ip.mtudisctimeout
-Returns the number of seconds in which a route added by the Path MTU
+Number of seconds in which a route added by the Path MTU
 Discovery engine will time out.
 When the route times out, the Path MTU Discovery engine will attempt
 to probe a larger path MTU.
@@ -1682,6 +1682,7 @@ The currently defined protocols and name
 .It ip6 Ta maxifprefixes Ta integer Ta yes
 .It ip6 Ta maxifdefrouters Ta integer Ta yes
 .It ip6 Ta mforwarding Ta integer Ta yes
+.It ip6 Ta mtudisctimeout Ta integer Ta yes
 .It ip6 Ta multicast_mtudisc Ta integer Ta yes
 .It ip6 Ta multipath Ta integer Ta yes
 .It ip6 Ta neighborgcthresh Ta integer Ta yes
@@ -1881,6 +1882,10 @@ If set to 0, the ICMPv6 Too Big message 
 This variable enables multipath routing for IPv6 addresses.
 If set to 0, only the first route selected will be used for a given
 destination regardless of how many routes exist in the routing table.
+.Pp
+.It Li ip6.mtudisctimeout
+Number of seconds in which a route added by the Path MTU
+Discovery engine will time out.
 .Pp
 .It Li ip6.neighborgcthresh
 Maximum number of entries in neighbor cache.



Re: IPv6 mtudisctimeout sysctl man page fix

2014-04-19 Thread Loganaden Velvindron
On Sat, Apr 19, 2014 at 08:19:23AM -0700, Loganaden Velvindron wrote:
 On Sat, Apr 19, 2014 at 07:51:34AM -0700, Loganaden Velvindron wrote:
  Hi All,
  
  The code was added for MTU discovery timeout in IPv6, but the man 
  page misses the description.
  
  Feedback welcomed.
  
  
 
 s/icmp6/ip6 from henning@ and sthen@, and change from Return the number of
 seconds to Number of Seconds for both IPv4 and IPv6.
 
Added a bit more description for IPv6.

Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.174
diff -u -p -u -p -r1.174 sysctl.8
--- sbin/sysctl/sysctl.819 Apr 2014 12:42:50 -  1.174
+++ sbin/sysctl/sysctl.819 Apr 2014 16:04:37 -
@@ -306,6 +306,7 @@ and a few require a kernel compiled with
 .It net.inet6.ip6.maxifprefixes Ta integer Ta yes
 .It net.inet6.ip6.maxifdefrouters Ta integer Ta yes
 .It net.inet6.ip6.mforwarding Ta integer Ta yes
+.It net.inet6.ip6.mtudisctimeout Ta integer Ta yes
 .It net.inet6.ip6.multipath Ta integer Ta yes
 .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
 .It net.inet6.ip6.neighborgcthresh Ta integer Ta yes
Index: lib/libc/gen/sysctl.3
===
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.229
diff -u -p -u -p -r1.229 sysctl.3
--- lib/libc/gen/sysctl.3   19 Apr 2014 12:42:50 -  1.229
+++ lib/libc/gen/sysctl.3   19 Apr 2014 16:04:38 -
@@ -1476,7 +1476,7 @@ The default is 0.
 .It Li ip.mtudisc
 Returns 1 if Path MTU Discovery is enabled.
 .It Li ip.mtudisctimeout
-Returns the number of seconds in which a route added by the Path MTU
+Number of seconds in which a route added by the Path MTU
 Discovery engine will time out.
 When the route times out, the Path MTU Discovery engine will attempt
 to probe a larger path MTU.
@@ -1682,6 +1682,7 @@ The currently defined protocols and name
 .It ip6 Ta maxifprefixes Ta integer Ta yes
 .It ip6 Ta maxifdefrouters Ta integer Ta yes
 .It ip6 Ta mforwarding Ta integer Ta yes
+.It ip6 Ta mtudisctimeout Ta integer Ta yes
 .It ip6 Ta multicast_mtudisc Ta integer Ta yes
 .It ip6 Ta multipath Ta integer Ta yes
 .It ip6 Ta neighborgcthresh Ta integer Ta yes
@@ -1881,6 +1882,12 @@ If set to 0, the ICMPv6 Too Big message 
 This variable enables multipath routing for IPv6 addresses.
 If set to 0, only the first route selected will be used for a given
 destination regardless of how many routes exist in the routing table.
+.Pp
+.It Li ip6.mtudisctimeout
+Number of seconds in which a route added by the Path MTU
+Discovery engine will time out.
+When the route times out, the Path MTU Discovery engine will attempt
+to probe a larger path MTU.
 .Pp
 .It Li ip6.neighborgcthresh
 Maximum number of entries in neighbor cache.



sftp upload resume diff

2014-04-16 Thread Loganaden Velvindron
Hi All,

First version of the diff:

It works fine for resuming uploads. I'm going to upload a 2nd
revision soon.


Index: sftp-client.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v
retrieving revision 1.114
diff -u -p -u -p -r1.114 sftp-client.c
--- sftp-client.c   31 Jan 2014 16:39:19 -  1.114
+++ sftp-client.c   16 Apr 2014 13:33:27 -
@@ -1409,7 +1409,7 @@ download_dir(struct sftp_conn *conn, cha
 
 int
 do_upload(struct sftp_conn *conn, char *local_path, char *remote_path,
-int preserve_flag, int fsync_flag)
+int preserve_flag, int resume, int fsync_flag)
 {
int local_fd;
int status = SSH2_FX_OK;
@@ -1418,7 +1418,7 @@ do_upload(struct sftp_conn *conn, char *
char *handle, *data;
Buffer msg;
struct stat sb;
-   Attrib a;
+   Attrib a, *c = NULL;
u_int32_t startid;
u_int32_t ackid;
struct outstanding_ack {
@@ -1456,6 +1456,26 @@ do_upload(struct sftp_conn *conn, char *
if (!preserve_flag)
a.flags = ~SSH2_FILEXFER_ATTR_ACMODTIME;
 
+   if (resume) {
+   /* Get remote file size if it exists */
+   if ((c = do_stat(conn, remote_path, 0)) == NULL) {
+   close(local_fd);
+   return -1;
+   }
+
+   if ((off_t)c-size  sb.st_size || 
+  (off_t)c-size == sb.st_size) {
+   error(destination file bigger or same size as source 
file);
+   close(local_fd);
+   return -1;
+   }
+
+   if (lseek(local_fd, (off_t)c-size, SEEK_SET) == -1) {
+   close(local_fd);
+   return -1;
+   }
+   }
+
buffer_init(msg);
 
/* Send open request */
@@ -1463,7 +1483,8 @@ do_upload(struct sftp_conn *conn, char *
buffer_put_char(msg, SSH2_FXP_OPEN);
buffer_put_int(msg, id);
buffer_put_cstring(msg, remote_path);
-   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|SSH2_FXF_TRUNC);
+   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|
+ (resume ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC));
encode_attrib(msg, a);
send_msg(conn, msg);
debug3(Sent message SSH2_FXP_OPEN I:%u P:%s, id, remote_path);
@@ -1482,7 +1503,7 @@ do_upload(struct sftp_conn *conn, char *
data = xmalloc(conn-transfer_buflen);
 
/* Read from local and write to remote */
-   offset = progress_counter = 0;
+   offset = progress_counter = (resume ? c-size : 0);
if (showprogress)
start_progress_meter(local_path, sb.st_size,
progress_counter);
@@ -1596,7 +1617,7 @@ do_upload(struct sftp_conn *conn, char *
 
 static int
 upload_dir_internal(struct sftp_conn *conn, char *src, char *dst, int depth,
-int preserve_flag, int print_flag, int fsync_flag)
+int preserve_flag, int print_flag, int resume, int fsync_flag)
 {
int ret = 0, status;
DIR *dirp;
@@ -1665,12 +1686,12 @@ upload_dir_internal(struct sftp_conn *co
continue;
 
if (upload_dir_internal(conn, new_src, new_dst,
-   depth + 1, preserve_flag, print_flag,
+   depth + 1, preserve_flag, print_flag, resume,
fsync_flag) == -1)
ret = -1;
} else if (S_ISREG(sb.st_mode)) {
if (do_upload(conn, new_src, new_dst,
-   preserve_flag, fsync_flag) == -1) {
+   preserve_flag, resume, fsync_flag) == -1) {
error(Uploading of file %s to %s failed!,
new_src, new_dst);
ret = -1;
@@ -1689,7 +1710,7 @@ upload_dir_internal(struct sftp_conn *co
 
 int
 upload_dir(struct sftp_conn *conn, char *src, char *dst, int preserve_flag,
-int print_flag, int fsync_flag)
+int print_flag, int resume, int fsync_flag)
 {
char *dst_canon;
int ret;
@@ -1700,7 +1721,7 @@ upload_dir(struct sftp_conn *conn, char 
}
 
ret = upload_dir_internal(conn, src, dst_canon, 0, preserve_flag,
-   print_flag, fsync_flag);
+   print_flag, resume, fsync_flag);
 
free(dst_canon);
return ret;
Index: sftp-client.h
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.h,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 sftp-client.h
--- sftp-client.h   17 Oct 2013 00:30:13 -  1.24
+++ sftp-client.h   16 Apr 2014 13:33:27 -
@@ -120,13 +120,13 @@ int download_dir(struct sftp_conn *, cha
  * Upload 'local_path' to 'remote_path'. Preserve permissions and times
  * if 'pflag' 

Re: sftp upload resume diff

2014-04-16 Thread Loganaden Velvindron
Hi,

Fixed the style issue for an error() line that Mike Larkin
pointed out to me.

Index: usr.bin/ssh/sftp-client.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v
retrieving revision 1.114
diff -u -p -u -p -r1.114 sftp-client.c
--- usr.bin/ssh/sftp-client.c   31 Jan 2014 16:39:19 -  1.114
+++ usr.bin/ssh/sftp-client.c   16 Apr 2014 14:03:05 -
@@ -1409,7 +1409,7 @@ download_dir(struct sftp_conn *conn, cha
 
 int
 do_upload(struct sftp_conn *conn, char *local_path, char *remote_path,
-int preserve_flag, int fsync_flag)
+int preserve_flag, int resume, int fsync_flag)
 {
int local_fd;
int status = SSH2_FX_OK;
@@ -1418,7 +1418,7 @@ do_upload(struct sftp_conn *conn, char *
char *handle, *data;
Buffer msg;
struct stat sb;
-   Attrib a;
+   Attrib a, *c = NULL;
u_int32_t startid;
u_int32_t ackid;
struct outstanding_ack {
@@ -1456,6 +1456,27 @@ do_upload(struct sftp_conn *conn, char *
if (!preserve_flag)
a.flags = ~SSH2_FILEXFER_ATTR_ACMODTIME;
 
+   if (resume) {
+   /* Get remote file size if it exists */
+   if ((c = do_stat(conn, remote_path, 0)) == NULL) {
+   close(local_fd);
+   return -1;
+   }
+
+   if ((off_t)c-size  sb.st_size || 
+  (off_t)c-size == sb.st_size) {
+   error(destination file bigger or same size as 
+ source file);
+   close(local_fd);
+   return -1;
+   }
+
+   if (lseek(local_fd, (off_t)c-size, SEEK_SET) == -1) {
+   close(local_fd);
+   return -1;
+   }
+   }
+
buffer_init(msg);
 
/* Send open request */
@@ -1463,7 +1484,8 @@ do_upload(struct sftp_conn *conn, char *
buffer_put_char(msg, SSH2_FXP_OPEN);
buffer_put_int(msg, id);
buffer_put_cstring(msg, remote_path);
-   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|SSH2_FXF_TRUNC);
+   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|
+ (resume ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC));
encode_attrib(msg, a);
send_msg(conn, msg);
debug3(Sent message SSH2_FXP_OPEN I:%u P:%s, id, remote_path);
@@ -1482,7 +1504,7 @@ do_upload(struct sftp_conn *conn, char *
data = xmalloc(conn-transfer_buflen);
 
/* Read from local and write to remote */
-   offset = progress_counter = 0;
+   offset = progress_counter = (resume ? c-size : 0);
if (showprogress)
start_progress_meter(local_path, sb.st_size,
progress_counter);
@@ -1596,7 +1618,7 @@ do_upload(struct sftp_conn *conn, char *
 
 static int
 upload_dir_internal(struct sftp_conn *conn, char *src, char *dst, int depth,
-int preserve_flag, int print_flag, int fsync_flag)
+int preserve_flag, int print_flag, int resume, int fsync_flag)
 {
int ret = 0, status;
DIR *dirp;
@@ -1665,12 +1687,12 @@ upload_dir_internal(struct sftp_conn *co
continue;
 
if (upload_dir_internal(conn, new_src, new_dst,
-   depth + 1, preserve_flag, print_flag,
+   depth + 1, preserve_flag, print_flag, resume,
fsync_flag) == -1)
ret = -1;
} else if (S_ISREG(sb.st_mode)) {
if (do_upload(conn, new_src, new_dst,
-   preserve_flag, fsync_flag) == -1) {
+   preserve_flag, resume, fsync_flag) == -1) {
error(Uploading of file %s to %s failed!,
new_src, new_dst);
ret = -1;
@@ -1689,7 +1711,7 @@ upload_dir_internal(struct sftp_conn *co
 
 int
 upload_dir(struct sftp_conn *conn, char *src, char *dst, int preserve_flag,
-int print_flag, int fsync_flag)
+int print_flag, int resume, int fsync_flag)
 {
char *dst_canon;
int ret;
@@ -1700,7 +1722,7 @@ upload_dir(struct sftp_conn *conn, char 
}
 
ret = upload_dir_internal(conn, src, dst_canon, 0, preserve_flag,
-   print_flag, fsync_flag);
+   print_flag, resume, fsync_flag);
 
free(dst_canon);
return ret;
Index: usr.bin/ssh/sftp-client.h
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.h,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 sftp-client.h
--- usr.bin/ssh/sftp-client.h   17 Oct 2013 00:30:13 -  1.24
+++ usr.bin/ssh/sftp-client.h   16 Apr 2014 14:03:05 -
@@ -120,13 +120,13 @@ int download_dir(struct sftp_conn *, cha
  * Upload 'local_path' to 

Re: sftp upload resume diff

2014-04-16 Thread Loganaden Velvindron
Rework the wording for uploading resume as suggested by Mike Larkin.

(More tweaks coming up soon)


Index: sftp-client.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v
retrieving revision 1.114
diff -u -p -u -p -r1.114 sftp-client.c
--- sftp-client.c   31 Jan 2014 16:39:19 -  1.114
+++ sftp-client.c   16 Apr 2014 14:14:34 -
@@ -1409,7 +1409,7 @@ download_dir(struct sftp_conn *conn, cha
 
 int
 do_upload(struct sftp_conn *conn, char *local_path, char *remote_path,
-int preserve_flag, int fsync_flag)
+int preserve_flag, int resume, int fsync_flag)
 {
int local_fd;
int status = SSH2_FX_OK;
@@ -1418,7 +1418,7 @@ do_upload(struct sftp_conn *conn, char *
char *handle, *data;
Buffer msg;
struct stat sb;
-   Attrib a;
+   Attrib a, *c = NULL;
u_int32_t startid;
u_int32_t ackid;
struct outstanding_ack {
@@ -1456,6 +1456,27 @@ do_upload(struct sftp_conn *conn, char *
if (!preserve_flag)
a.flags = ~SSH2_FILEXFER_ATTR_ACMODTIME;
 
+   if (resume) {
+   /* Get remote file size if it exists */
+   if ((c = do_stat(conn, remote_path, 0)) == NULL) {
+   close(local_fd);
+   return -1;
+   }
+
+   if ((off_t)c-size  sb.st_size || 
+  (off_t)c-size == sb.st_size) {
+   error(destination file bigger or same size as 
+ source file);
+   close(local_fd);
+   return -1;
+   }
+
+   if (lseek(local_fd, (off_t)c-size, SEEK_SET) == -1) {
+   close(local_fd);
+   return -1;
+   }
+   }
+
buffer_init(msg);
 
/* Send open request */
@@ -1463,7 +1484,8 @@ do_upload(struct sftp_conn *conn, char *
buffer_put_char(msg, SSH2_FXP_OPEN);
buffer_put_int(msg, id);
buffer_put_cstring(msg, remote_path);
-   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|SSH2_FXF_TRUNC);
+   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|
+ (resume ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC));
encode_attrib(msg, a);
send_msg(conn, msg);
debug3(Sent message SSH2_FXP_OPEN I:%u P:%s, id, remote_path);
@@ -1482,7 +1504,7 @@ do_upload(struct sftp_conn *conn, char *
data = xmalloc(conn-transfer_buflen);
 
/* Read from local and write to remote */
-   offset = progress_counter = 0;
+   offset = progress_counter = (resume ? c-size : 0);
if (showprogress)
start_progress_meter(local_path, sb.st_size,
progress_counter);
@@ -1596,7 +1618,7 @@ do_upload(struct sftp_conn *conn, char *
 
 static int
 upload_dir_internal(struct sftp_conn *conn, char *src, char *dst, int depth,
-int preserve_flag, int print_flag, int fsync_flag)
+int preserve_flag, int print_flag, int resume, int fsync_flag)
 {
int ret = 0, status;
DIR *dirp;
@@ -1665,12 +1687,12 @@ upload_dir_internal(struct sftp_conn *co
continue;
 
if (upload_dir_internal(conn, new_src, new_dst,
-   depth + 1, preserve_flag, print_flag,
+   depth + 1, preserve_flag, print_flag, resume,
fsync_flag) == -1)
ret = -1;
} else if (S_ISREG(sb.st_mode)) {
if (do_upload(conn, new_src, new_dst,
-   preserve_flag, fsync_flag) == -1) {
+   preserve_flag, resume, fsync_flag) == -1) {
error(Uploading of file %s to %s failed!,
new_src, new_dst);
ret = -1;
@@ -1689,7 +1711,7 @@ upload_dir_internal(struct sftp_conn *co
 
 int
 upload_dir(struct sftp_conn *conn, char *src, char *dst, int preserve_flag,
-int print_flag, int fsync_flag)
+int print_flag, int resume, int fsync_flag)
 {
char *dst_canon;
int ret;
@@ -1700,7 +1722,7 @@ upload_dir(struct sftp_conn *conn, char 
}
 
ret = upload_dir_internal(conn, src, dst_canon, 0, preserve_flag,
-   print_flag, fsync_flag);
+   print_flag, resume, fsync_flag);
 
free(dst_canon);
return ret;
Index: sftp-client.h
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.h,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 sftp-client.h
--- sftp-client.h   17 Oct 2013 00:30:13 -  1.24
+++ sftp-client.h   16 Apr 2014 14:14:34 -
@@ -120,13 +120,13 @@ int download_dir(struct sftp_conn *, cha
  * Upload 'local_path' to 'remote_path'. Preserve permissions and times
  

Re: sftp upload resume diff

2014-04-16 Thread Loganaden Velvindron
Use = instead of == ||  for file size comparison as pointed
out by Okan Demirmen.

Index: sftp-client.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v
retrieving revision 1.114
diff -u -p -u -p -r1.114 sftp-client.c
--- sftp-client.c   31 Jan 2014 16:39:19 -  1.114
+++ sftp-client.c   16 Apr 2014 14:42:04 -
@@ -1409,7 +1409,7 @@ download_dir(struct sftp_conn *conn, cha
 
 int
 do_upload(struct sftp_conn *conn, char *local_path, char *remote_path,
-int preserve_flag, int fsync_flag)
+int preserve_flag, int resume, int fsync_flag)
 {
int local_fd;
int status = SSH2_FX_OK;
@@ -1418,7 +1418,7 @@ do_upload(struct sftp_conn *conn, char *
char *handle, *data;
Buffer msg;
struct stat sb;
-   Attrib a;
+   Attrib a, *c = NULL;
u_int32_t startid;
u_int32_t ackid;
struct outstanding_ack {
@@ -1456,6 +1456,26 @@ do_upload(struct sftp_conn *conn, char *
if (!preserve_flag)
a.flags = ~SSH2_FILEXFER_ATTR_ACMODTIME;
 
+   if (resume) {
+   /* Get remote file size if it exists */
+   if ((c = do_stat(conn, remote_path, 0)) == NULL) {
+   close(local_fd);
+   return -1;
+   }
+
+   if ((off_t)c-size = sb.st_size) {
+   error(destination file bigger or same size as 
+ source file);
+   close(local_fd);
+   return -1;
+   }
+
+   if (lseek(local_fd, (off_t)c-size, SEEK_SET) == -1) {
+   close(local_fd);
+   return -1;
+   }
+   }
+
buffer_init(msg);
 
/* Send open request */
@@ -1463,7 +1483,8 @@ do_upload(struct sftp_conn *conn, char *
buffer_put_char(msg, SSH2_FXP_OPEN);
buffer_put_int(msg, id);
buffer_put_cstring(msg, remote_path);
-   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|SSH2_FXF_TRUNC);
+   buffer_put_int(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT|
+ (resume ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC));
encode_attrib(msg, a);
send_msg(conn, msg);
debug3(Sent message SSH2_FXP_OPEN I:%u P:%s, id, remote_path);
@@ -1482,7 +1503,7 @@ do_upload(struct sftp_conn *conn, char *
data = xmalloc(conn-transfer_buflen);
 
/* Read from local and write to remote */
-   offset = progress_counter = 0;
+   offset = progress_counter = (resume ? c-size : 0);
if (showprogress)
start_progress_meter(local_path, sb.st_size,
progress_counter);
@@ -1596,7 +1617,7 @@ do_upload(struct sftp_conn *conn, char *
 
 static int
 upload_dir_internal(struct sftp_conn *conn, char *src, char *dst, int depth,
-int preserve_flag, int print_flag, int fsync_flag)
+int preserve_flag, int print_flag, int resume, int fsync_flag)
 {
int ret = 0, status;
DIR *dirp;
@@ -1665,12 +1686,12 @@ upload_dir_internal(struct sftp_conn *co
continue;
 
if (upload_dir_internal(conn, new_src, new_dst,
-   depth + 1, preserve_flag, print_flag,
+   depth + 1, preserve_flag, print_flag, resume,
fsync_flag) == -1)
ret = -1;
} else if (S_ISREG(sb.st_mode)) {
if (do_upload(conn, new_src, new_dst,
-   preserve_flag, fsync_flag) == -1) {
+   preserve_flag, resume, fsync_flag) == -1) {
error(Uploading of file %s to %s failed!,
new_src, new_dst);
ret = -1;
@@ -1689,7 +1710,7 @@ upload_dir_internal(struct sftp_conn *co
 
 int
 upload_dir(struct sftp_conn *conn, char *src, char *dst, int preserve_flag,
-int print_flag, int fsync_flag)
+int print_flag, int resume, int fsync_flag)
 {
char *dst_canon;
int ret;
@@ -1700,7 +1721,7 @@ upload_dir(struct sftp_conn *conn, char 
}
 
ret = upload_dir_internal(conn, src, dst_canon, 0, preserve_flag,
-   print_flag, fsync_flag);
+   print_flag, resume, fsync_flag);
 
free(dst_canon);
return ret;
Index: sftp-client.h
===
RCS file: /cvs/src/usr.bin/ssh/sftp-client.h,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 sftp-client.h
--- sftp-client.h   17 Oct 2013 00:30:13 -  1.24
+++ sftp-client.h   16 Apr 2014 14:42:04 -
@@ -120,13 +120,13 @@ int download_dir(struct sftp_conn *, cha
  * Upload 'local_path' to 'remote_path'. Preserve permissions and times
  * if 'pflag' is set
  */
-int do_upload(struct sftp_conn *, char *, 

Re: OpenBSD Foundation 2014 Fundraising Campaign.

2014-04-10 Thread Loganaden Velvindron
On Thu, Apr 10, 2014 at 8:23 PM, Bob Beck b...@openbsdfoundation.org wrote:

 The OpenBSD Foundation is happy to report that the $150,000 goal of the 2014
 fundraising campaign has been reached.

 We wish to thank our contributors large and small. We will continue
 our fundraising efforts both in the current year and next year.

 The success of this year's effort has allowed the Foundation to
 reverse the recent decline in the support we were able to offer the
 OpenBSD project. The Foundation has been able to assume responsibility
 for funding more aspects of the project infrastructure, such as the
 server electricity bill.

 The Foundation is now able to support efforts underway to rebuild a
 significant part of the project server infrastructure. This included a
 few things that were, literally, rotting.

 2014's slate of hackathons has been solidified, ensuring these critical
 events will continue to provide a stream of improvements to the OpenBSD
 and related projects.

 We would like to especially thank the contributors who have made
 commitments for continuing donations to the Foundation. Every
 recurring regular donation allows us to budget and plan more
 effectively.

 The Foundation will continue to strive to improve its financial
 resources, and hopes to be able to provide further support to the
 projects in the future. Please continue to contribute!


Congratulations !

$200k as target next year :-)

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: Do you use IPv6?

2014-03-31 Thread Loganaden Velvindron
I'll give it a try when I get home :)


On Mon, Mar 31, 2014 at 6:30 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 On 27/03/14(Thu) 15:14, Martin Pieuchot wrote:
 If you do, please test the diff below and make sure it does not change
 anything in your routing table!

 This diff is a first step to merge all the various code paths that
 manipulate auto-magically created routes.  While the code in sys/netinet
 makes use of rtinit() to create routes with the RTP_CONNECTED priority,
 in sys/netinet6 land there is no equivalent.

 The diff below only deals with routes to loopback for IPv6 addresses.
 These routes are used to indicate that an address is local and that lo0
 should be used instead of the interface to output packets.  When you
 look at your routing table these routes have lo0 as Iface but their
 prefix correspond to the real interface, for example:


 DestinationGatewayFlags   
 Refs  Use   Mtu  Prio Iface
 ...
 fe80::200:5eff:fe00:102%carp2  00:00:5e:00:01:02  UHL
 00 - 4 lo0



 So the diff below makes use of the actual rtinit() code to create such
 routes, but introduce a new interface: rt_ifa_addloop()  rt_ifa_delloop()

 The next step will be to replace rtinit() by the underlying functions
 introduced in this diff: rt_ifa_add() and rt_ifa_del(), and document
 them.  Once that's done we should be able to replace any custom code
 creating or deleting a route with RTP_CONNECTED by one of these
 functions.

 Here is the diff, ok?

 Anybody?


 Index: net/route.c
 ===
 RCS file: /home/ncvs/src/sys/net/route.c,v
 retrieving revision 1.157
 diff -u -p -r1.157 route.c
 --- net/route.c   27 Mar 2014 10:39:23 -  1.157
 +++ net/route.c   27 Mar 2014 13:48:39 -
 @@ -150,6 +150,9 @@ int   rtflushclone1(struct radix_node *, v
  void rtflushclone(struct radix_node_head *, struct rtentry *);
  int  rt_if_remove_rtdelete(struct radix_node *, void *, u_int);

 +int  rt_ifa_add(struct ifaddr *, int, struct sockaddr *);
 +int  rt_ifa_del(struct ifaddr *, int, struct sockaddr *);
 +
  #define  LABELID_MAX 5

  struct rt_label {
 @@ -1083,67 +1086,46 @@ rt_maskedcopy(struct sockaddr *src, stru
  int
  rtinit(struct ifaddr *ifa, int cmd, int flags)
  {
 - struct rtentry  *rt;
 - struct sockaddr *dst, *deldst;
 - struct mbuf *m = NULL;
 - struct rtentry  *nrt = NULL;
 - int  error;
 - struct rt_addrinfo   info;
 + struct sockaddr *dst;
 + int error;
 +
 + KASSERT(cmd == RTM_ADD || cmd == RTM_DELETE);
 +
 + dst = flags  RTF_HOST ? ifa-ifa_dstaddr : ifa-ifa_addr;
 +
 + if (cmd == RTM_ADD)
 + error = rt_ifa_add(ifa, flags, dst);
 + else
 + error = rt_ifa_del(ifa, flags, dst);
 +
 + return (error);
 +}
 +
 +int
 +rt_ifa_add(struct ifaddr *ifa, int flags, struct sockaddr *dst)
 +{
 + struct rtentry  *rt, *nrt = NULL;
   struct sockaddr_rtlabel  sa_rl;
 + struct rt_addrinfo   info;
   u_short  rtableid = ifa-ifa_ifp-if_rdomain;
 + int  error;

 - dst = flags  RTF_HOST ? ifa-ifa_dstaddr : ifa-ifa_addr;
 - if (cmd == RTM_DELETE) {
 - if ((flags  RTF_HOST) == 0  ifa-ifa_netmask) {
 - m = m_get(M_DONTWAIT, MT_SONAME);
 - if (m == NULL)
 - return (ENOBUFS);
 - deldst = mtod(m, struct sockaddr *);
 - rt_maskedcopy(dst, deldst, ifa-ifa_netmask);
 - dst = deldst;
 - }
 - if ((rt = rtalloc1(dst, 0, rtableid)) != NULL) {
 - rt-rt_refcnt--;
 - /* try to find the right route */
 - while (rt  rt-rt_ifa != ifa)
 - rt = (struct rtentry *)
 - ((struct radix_node *)rt)-rn_dupedkey;
 - if (!rt) {
 - if (m != NULL)
 - (void) m_free(m);
 - return (flags  RTF_HOST ? EHOSTUNREACH
 - : ENETUNREACH);
 - }
 - }
 - }
 - bzero(info, sizeof(info));
 + memset(info, 0, sizeof(info));
   info.rti_ifa = ifa;
   info.rti_flags = flags;
   info.rti_info[RTAX_DST] = dst;
 - if (cmd == RTM_ADD)
 - info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
 + info.rti_info[RTAX_GATEWAY] = ifa-ifa_addr;
   info.rti_info[RTAX_LABEL] =
   rtlabel_id2sa(ifa-ifa_ifp-if_rtlabelid, sa_rl);

   if ((flags  RTF_HOST) == 0)
   info.rti_info[RTAX_NETMASK] = ifa-ifa_netmask;

 - error = rtrequest1(cmd, info, RTP_CONNECTED, nrt, 

Re: HEADS UP: librt revert

2014-03-23 Thread Loganaden Velvindron
On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie es...@nerim.net wrote:
 kili@  just committed a revert of the librt addition in src and corresponding
 patches in ports.

 If you've built a tree with librt, you want to
 # rm -f /usr/lib/librt.a

 This lib was added to facilitate porting software, as posix asks for it.
 but since it's only a stub, it was only added as a static library. No-one
 would approve a shared library, as that would waste space.

 Unfortunately, libtool (ours and gnu's) don't cope well with static-only
 libraries.  The untested commit of librt in source broke the ports tree.

 Specifically, programs such as x11/vlc, multimedia/xine-lib, or lang/php
 would no longer build (all 3 are using mutant versions of gnu libtool).

 It's possible further breakage would happen, but those 3 were broken.

 After almost a week (!), there has been exactly zero activity to fix the
 breakage.  No-one volunteered to do the requisite patches, and well,
 these ports are not exactly low profile, we need a ports tree in working
 condition to be able to conduct other work (such as the pending update to
 perl, or some other clean-up work).

That's very sad. I get the impression that there aren't many active
developers (?)



 So for now, the librt experiment got reverted. Maybe temporarily ().
 If people really want it in, they had better be willing to figure out
 how to fix the libtool breakage first...




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: HEADS UP: librt revert

2014-03-23 Thread Loganaden Velvindron
On Sun, Mar 23, 2014 at 10:46 PM, Loganaden Velvindron
logana...@gmail.com wrote:
 On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie es...@nerim.net wrote:
 kili@  just committed a revert of the librt addition in src and corresponding
 patches in ports.

 If you've built a tree with librt, you want to
 # rm -f /usr/lib/librt.a

 This lib was added to facilitate porting software, as posix asks for it.
 but since it's only a stub, it was only added as a static library. No-one
 would approve a shared library, as that would waste space.

 Unfortunately, libtool (ours and gnu's) don't cope well with static-only
 libraries.  The untested commit of librt in source broke the ports tree.

 Specifically, programs such as x11/vlc, multimedia/xine-lib, or lang/php
 would no longer build (all 3 are using mutant versions of gnu libtool).

 It's possible further breakage would happen, but those 3 were broken.

 After almost a week (!), there has been exactly zero activity to fix the
 breakage.  No-one volunteered to do the requisite patches, and well,
 these ports are not exactly low profile, we need a ports tree in working
 condition to be able to conduct other work (such as the pending update to
 perl, or some other clean-up work).

 That's very sad. I get the impression that there aren't many active
 developers (?)

Sorry, this shouldn't have been sent :-(

Please ignore.





 So for now, the librt experiment got reverted. Maybe temporarily ().
 If people really want it in, they had better be willing to figure out
 how to fix the libtool breakage first...




 --
 This message is strictly personal and the opinions expressed do not
 represent those of my employers, either past or present.



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 10:08 AM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
 On 3/12/14 11:15 PM, Loganaden Velvindron wrote:
 I've read about the file vulnerability, and capsicumization also
 came to mind. However, there was also a discussion when i was
 playing with capsicum and openssh, about the limits of capsicum.
 Capsicum doesn't prevent DoS, and we still need rlimit on FreeBSD
 in addition to capsicum.

 Yep, I consider it as an incremental improvement, not a complete
 solution.

 I would suggest that you come up with a regression plan to test
 the demons in base and the most popular one in ports. In this
 case, unbound was not capsicumised, but the changes made to the
 kernel affected unbound.

 I plan to build a src/regress/sys/kern/capsicum as I implement
 various functionality, but as for other services and such, I'm not
 sure how best to go about formally testing that. For larger
 integration-test stuff I generally just throw all my experimental
 code on all my production boxes and watch what happens. The more
 people who use those services the better because if something is
 broken I'll find out earlier and I can fix it. That's also the
 impression I got of how the pre-release testing cycle seems to work
 here.

I'm not a mentor, but I'd be happy to help you in any way I can. You
can send mails
to  tech@ for testing your diffs.

Also, it will probably help to contact the port maintainers as well, and ask
them to test the capsicum diffs, to make sure that we don't end up with things
like unbound crashing on OpenBSD.



 Also, please look into FreeBSD's regression test suite for capsicum.

 I'm aware of:
 http://svnweb.freebsd.org/base/head/tools/regression/security/cap_test/
 http://svnweb.freebsd.org/base/head/tools/regression/capsicum/
 https://github.com/google/capsicum-test

 is there something else?

Those are what I'm aware as well.


 Good testing coverage is also very important

 Agreed.

 There's going to be a lot of follow-up to do. I would suggest
 that you contact the maintainers and see who is interested in getting
 capsicum into their demon.  The response may be varied.

 I was going to wait until it's at a usable state before I solicit
 effort from others, otherwise it's just pointless discussion, but
 yes, that's the plan. In the mean time, I'll just shut up and hack.

What I'm referring to here is that some developers are interested in
capsicum, and
others are less interested. If you plan on working on capsicum on say
ntpd, then it
would help to contact the maintainer of ntp and see if he's
interested. If he is, then
you can put it on your workplan for your gsoc. It doesn't help much if
there is no interest
in merging the code upstream IMHO.

Please see this discussion for opensmtpd:
https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html



 The patches will probably be peer reviewed by many people, as
 capsicum touches different areas of the kernel. This process will
 take time.

 Naturally. I'd expect nothing less! :)

I hope that you will stick around after the gsoc :-)





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 10:57 AM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
 On 3/13/14 2:39 AM, Loganaden Velvindron wrote:
 I'm not a mentor, but I'd be happy to help you in any way I can.
 You can send mails to tech@ for testing your diffs.

 Any chance you'd like to review my bootloader patch from last month then?

I'm not a committer, but I can test your diff once I get back home. I
have a sparc64 machine.
It needs to powered on. Your best bet is asking a guy who hacks on
Sparc64. Check out the commit
logs to see who last hacked on that area.


 http://marc.info/?l=openbsd-techm=139408992902933

 I still haven't gotten any feedback.

 What I'm referring to here is that some developers are interested in
 capsicum, and others are less interested. If you plan on working on
 capsicum on say ntpd, then it would help to contact the maintainer of
 ntp and see if he's interested. If he is, then you can put it on your
 workplan for your gsoc. It doesn't help much if there is no interest
 in merging the code upstream IMHO.

 Please see this discussion for opensmtpd:
 https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html

 I see. OpenNTPD was actually one of the services I hilighted as a
 potentially good candidate in the short proposal thing I submitted
 as google's requirement.

Is that proposal available online ?


 I hope that you will stick around after the gsoc :-)

 Oh, I've been around a while, mostly just lurking, and I don't plan on
 going anywhere. The question is more about finding time to contribute.

:-)





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 11:44 AM, dpl tucha...@gmail.com wrote:
 Wow, I like to see this activity. I'm the one that started this thread.

 Jean-Phillipe: The main problem we'll have if both of us work on this is
 that it won't not be possible to work on userland if the kernel doesn't yet
 provide capability mode.

 Also, I think that both of us working in this project is not a good idea
 (specially given that what I liked most of this idea is the fact of getting
 to know the OpenBSD kernel, and work with it at the low level). FWIW, some
 future work with this would be great, but only after having the basic
 Capsicum support in the kernel.

 It's either that, or having a competition, and I would rather be able to
 work on something else than having a silly competition for a job, specially
 when there's a lot of work to be done :)

 Loganaden, many thanks for the awesome email(s) you sent here.
 I already contacted the Implement clang/llvm static code checker mentor,
 and he is quite responsive, so it seems that I just have found my proposal
 for OpenBSD :)

(Logan's fine)

Great !

If you have friends in your university who are interested in OpenBSD
and security stuff,
please let them know about OpenBSD's GSOC for this year !


 Many thanks to everyone, and I'm happy to see that from this thread has
 sprung some activity over here.

You're welcome.


 2014-03-12 22:01 GMT+01:00 Jean-Philippe Ouellet jean-phili...@ouellet.biz
 :

 On 3/12/14 4:58 AM, tuchalia wrote:
  Should l try to port also the Casper daemon to OpenBSD,  or
  only work in the kernel implementation?

 Based on more private mail, I figured it'd be a good idea to make what I
 plan to work on public in case there are others interested so we can
 avoid stepping on each others' toes.

 I've been told that the OpenBSD project's main objective in supporting
 capsicum is to have stronger privsep in our default services (think ssh,
 etc.) and the first steps to support that are the relevant kernel
 changes, therefore that's what I plan to work on first.

 I wasn't planning on doing anything with casper, user angels, etc. and
 even porting libcapsicum was a 2ndary objective, at least not during
 this summer.

 There's also a ton of userland things besides daemons/services that
 could (probably should) be capsicumized.

 Just yesterday there was just a vuln reported by the debian folks in
 their file(1) that potentially allowed arbitrary code execution. I
 immediately checked our implementation and didn't see the same code that
 was patched, but our src/usr.bin/file/softmagic.c still contains a ton
 of logic which probably has at least one bug somewhere, and file(1)
 should be a fairly easily capsicumizable utility.

 Userland capsicumization is something that could very easily be done by
 multiple people since it's naturally separated into small chunks (per
 utility). I planned to focus on getting the primary kernel
 infrastructure in place this summer (because it's a somewhat large
 project, and it would definitely help to be sponsored by Google so I can
 focus on it) and then it'd be easier to work on userland stuff in small
 chunks of free time throughout the next school year.

 The reason I really want to work on Capsicum is because it addresses my
 primary concern with OpenBSD: the poor availability of post-exploit
 mitigation techniques, especially post-parallelism with sysjail. I
 haven't completely bought into what appears to me to be Robert Watson's
 greater vision of a realistic transition path towards
 capability-oriented operating systems, I mostly just want to improve the
 tools I use every day.




 --
 Daniel



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-12 Thread Loganaden Velvindron
On Wed, Mar 12, 2014 at 12:58 PM, tuchalia tucha...@gmail.com wrote:
 Hi all,

 I'm really interested in this possibility of porting the Capsicum framework

That's awesome !

 to OpenBSD. Should l try to port also the Casper daemon to OpenBSD,  or
 only work in the kernel implementation?

Capsicum is a huge project, and realistically, it's impossible to to
port it completely
and get a production grade version by working only 8-12 weeks. The
project clearly exceeds
the mandate of a GSoC, in my opinion.

You might start by planning the kernel implementation, similar to what
Joris did for DragonflyBSD.
(http://leaf.dragonflybsd.org/mailarchive/kernel/2013-04/msg00025.html).

With a kernel implementation, we can do quite a lot of things, like
what happened for OpenSSH 6.5.
OpenSSH 6.5 has capsicum support on FreeBSD, and it doesn't need
casper to sandbox the pre-auth code.

matthew had already started working on some bits.
(https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2011-July/msg2.html)

Your best bet is to speak to damien miller and work out a sensible
plan. If you're really interested
motivated in doing a good  complete work, you should be ready to
spend time after gsoc getting feedback
on the diffs, and improve them.

Personally, I would like to see a working kernel implementation, and
getting at least sshd in base
capsicumised :-) I can help you with the last part, as I'm familiar
with the code. Please talk to damien  matthew
as they might have a different roadmap or radically different ideas in mind.



 I've used Capsicum during the last summer, but I only worked with the
 syscall API, that is, no Casper (something that can be fixed quickly).

Very good !

However, I would advise caution here, as there has been at least one
bug that has been reported
with the changes happening in FreeBSD.

(http://unbound.net/pipermail/unbound-users/2014-February/003169.html).
So you have to be prepared
to fix any potential fallout if capsicum port is to be merged into OpenBSD :-)



 I know what I should I do with the Capsicum side (in the matter of getting
 some info to have a strong proposal) but I'm not sure about where to look
 when it comes to the OpenBSD side. Should I take a look at the process data
 structure, and how all this is implemented in the kernel? Should I take a
 look somewhere else?

I would advise you to look into Joris's posts to DragonflyBSD lists,
and see what difficulties
he faced when he ported capsicum to dflybsd. Also, please take into
account that OpenBSD kernel
is different from FreeBSD kernel, and that will probably involve a lot
of rewriting.

You are lucky as OpenBSD has a rock solid -current tree. Ideally, you
would have a dedicated physical
box such as a 2nd laptop or a development machine to work on that IMHO.

Read the OpenBSD FAQ for running -current.
http://www.openbsd.org/faq/current.html


 Also,  do we have any IRC channel to discuss al this?

I'll send it to you in a personal mail.


 Many thanks,

Good luck with your proposal !


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-12 Thread Loganaden Velvindron
On Wed, Mar 12, 2014 at 10:49 PM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
 On 3/12/14 4:58 AM, tuchalia wrote:
 Hi all,

 I'm really interested in this possibility of porting the Capsicum framework
 to OpenBSD. Should l try to port also the Casper daemon to OpenBSD,  or
 only work in the kernel implementation?

 I've used Capsicum during the last summer, but I only worked with the
 syscall API, that is, no Casper (something that can be fixed quickly).

 I know what I should I do with the Capsicum side (in the matter of getting
 some info to have a strong proposal) but I'm not sure about where to look
 when it comes to the OpenBSD side. Should I take a look at the process data
 structure, and how all this is implemented in the kernel? Should I take a
 look somewhere else?

 Also,  do we have any IRC channel to discuss al this?

 Many thanks,


 I'm also interested in porting Capsicum, although so far all my emails
 about it have been off-list.

 I've already been in contact with dempsky@ (one of the listed mentors,
 and has previously done some work towards porting it) since before the
 OpenBSD Foundation announced it was applying for GSoC, and I submitted
 my application to Google when applications opened on the 10th. Hopefully
 I'll get accepted.

Great !


 If we both get accepted I think that could work well too, there's
 certainly enough work to do. We should just plan out what exactly we're
 each going to do to avoid stepping on each others' toes too much.
 Thankfully the API is already well defined thanks to FreeBSD so
 cooperating on different parts should be pretty easy, and it'd be nice
 to have another dedicated person to peer-review patches with.


If both of you are planning to work on capsicum, please consider making both
of your work plans available so that mentors can help you split the work.

The patches will probably be peer reviewed by many people, as capsicum touches
different areas of the kernel. This process will take time.


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-12 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 1:01 AM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
 On 3/12/14 4:58 AM, tuchalia wrote:
 Should l try to port also the Casper daemon to OpenBSD,  or
 only work in the kernel implementation?

 Based on more private mail, I figured it'd be a good idea to make what I
 plan to work on public in case there are others interested so we can
 avoid stepping on each others' toes.

 I've been told that the OpenBSD project's main objective in supporting
 capsicum is to have stronger privsep in our default services (think ssh,
 etc.) and the first steps to support that are the relevant kernel
 changes, therefore that's what I plan to work on first.

Also, please note that OpenBSD supports multiple architectures.


 I wasn't planning on doing anything with casper, user angels, etc. and
 even porting libcapsicum was a 2ndary objective, at least not during
 this summer.

Unbound crashes on FreeBSD-capsicum enabled kernels.
(http://unbound.net/pipermail/unbound-users/2014-February/003169.html)

I would suggest that you come up with a regression plan to test the demons
in base and the most popular one in ports. In this case, unbound was
not capsicumised,
but the changes made to the kernel affected unbound.

Also, please look into FreeBSD's regression test suite for capsicum.


 There's also a ton of userland things besides daemons/services that
 could (probably should) be capsicumized.

Good testing coverage is also very important, in addition to sandboxing.
There's going to be a lot of follow-up to do. I would suggest that you contact
the maintainers and see who is interested in getting capsicum into their demon.
The response may be varied.


 Just yesterday there was just a vuln reported by the debian folks in
 their file(1) that potentially allowed arbitrary code execution. I
 immediately checked our implementation and didn't see the same code that
 was patched, but our src/usr.bin/file/softmagic.c still contains a ton
 of logic which probably has at least one bug somewhere, and file(1)
 should be a fairly easily capsicumizable utility.

I've read about the file vulnerability , and capsicumization also came
to mind. However, there was also
a discussion when i was playing with capsicum and openssh, about the
limits of capsicum.
Capsicum doesn't prevent DoS, and we still need rlimit on FreeBSD in
addition to capsicum.

(https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2013-August/msg0.html)




 Userland capsicumization is something that could very easily be done by
 multiple people since it's naturally separated into small chunks (per
 utility). I planned to focus on getting the primary kernel
 infrastructure in place this summer (because it's a somewhat large
 project, and it would definitely help to be sponsored by Google so I can
 focus on it) and then it'd be easier to work on userland stuff in small
 chunks of free time throughout the next school year.

 The reason I really want to work on Capsicum is because it addresses my
 primary concern with OpenBSD: the poor availability of post-exploit
 mitigation techniques, especially post-parallelism with sysjail. I
 haven't completely bought into what appears to me to be Robert Watson's
 greater vision of a realistic transition path towards
 capability-oriented operating systems, I mostly just want to improve the
 tools I use every day.


Great !

-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



ip6_mroute.c: minor stats fix

2014-03-03 Thread Loganaden Velvindron
Hi All,

From FreeBSD,

Only count table lookups when we're actually processing packets.

Index: sys/netinet6/ip6_mroute.c
===
RCS file: /cvs/src/sys/netinet6/ip6_mroute.c,v
retrieving revision 1.67
diff -u -p -u -p -r1.67 ip6_mroute.c
--- sys/netinet6/ip6_mroute.c   11 Nov 2013 09:15:35 -  1.67
+++ sys/netinet6/ip6_mroute.c   3 Mar 2014 12:33:06 -
@@ -190,7 +190,6 @@ static int pim6;
 #define MF6CFIND(o, g, rt) do { \
struct mf6c *_rt = mf6ctable[MF6CHASH(o,g)]; \
rt = NULL; \
-   mrt6stat.mrt6s_mfc_lookups++; \
while (_rt) { \
if (IN6_ARE_ADDR_EQUAL(_rt-mf6c_origin.sin6_addr, (o))  \
IN6_ARE_ADDR_EQUAL(_rt-mf6c_mcastgrp.sin6_addr, (g))  \
@@ -247,7 +246,7 @@ int
 ip6_mrouter_set(int cmd, struct socket *so, struct mbuf *m)
 {
if (cmd != MRT6_INIT  so != ip6_mrouter)
-   return (EACCES);
+   return (EPERM);
 
switch (cmd) {
case MRT6_INIT:
@@ -287,7 +286,8 @@ ip6_mrouter_set(int cmd, struct socket *
 int
 ip6_mrouter_get(int cmd, struct socket *so, struct mbuf **m)
 {
-   if (so != ip6_mrouter) return EACCES;
+   if (so != ip6_mrouter)
+   return (EPERM);
 
*m = m_get(M_WAIT, MT_SOOPTS);
 
@@ -998,7 +998,7 @@ ip6_mforward(struct ip6_hdr *ip6, struct
 */
s = splsoftnet();
MF6CFIND(ip6-ip6_src, ip6-ip6_dst, rt);
-
+   mrt6stat.mrt6s_mfc_lookups++;
/* Entry exists, so forward if necessary */
if (rt) {
splx(s);



Re: sysctl.8: add missing mtudisctimeout for ipv6

2014-03-03 Thread Loganaden Velvindron
On Mon, Mar 3, 2014 at 5:41 PM, Jason McIntyre j...@kerhand.co.uk wrote:
 On Sun, Mar 02, 2014 at 10:51:22AM -0800, Loganaden Velvindron wrote:
 Hi,

 While going through some of the commit logs, I noticed
 that sysctl didn't list ip6.mtudisctimeout.

 Patch attached:

 Index: sbin/sysctl/sysctl.8
 ===
 RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
 retrieving revision 1.173
 diff -u -p -u -p -r1.173 sysctl.8
 --- sbin/sysctl/sysctl.8  28 Oct 2013 21:02:35 -  1.173
 +++ sbin/sysctl/sysctl.8  2 Mar 2014 18:45:29 -
 @@ -303,6 +303,7 @@ and a few require a kernel compiled with
  .It net.inet6.ip6.v6only Ta integer Ta no
  .It net.inet6.ip6.maxfrags Ta integer Ta yes
  .It net.inet6.ip6.mforwarding Ta integer Ta yes
 +.It net.inet6.ip6.mtudisctimeout Ta integer Ta yes
  .It net.inet6.ip6.multipath Ta integer Ta yes
  .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
  .It net.inet6.icmp6.rediraccept Ta integer Ta yes


 should be accompanied by a corresponding entry in sysctl(3), along with
 a description. i've no idea what this stuff does, and i'm not
 volunteering to go find out.

 i notice there's a few of the ip6 sysctls not documented...

I'm also working on that :-)



 jmc




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: sysctl.8: add missing mtudisctimeout for ipv6

2014-03-03 Thread Loganaden Velvindron
On Mon, Mar 3, 2014 at 5:41 PM, Jason McIntyre j...@kerhand.co.uk wrote:
 On Sun, Mar 02, 2014 at 10:51:22AM -0800, Loganaden Velvindron wrote:
 Hi,

 While going through some of the commit logs, I noticed
 that sysctl didn't list ip6.mtudisctimeout.

 Patch attached:

 Index: sbin/sysctl/sysctl.8
 ===
 RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
 retrieving revision 1.173
 diff -u -p -u -p -r1.173 sysctl.8
 --- sbin/sysctl/sysctl.8  28 Oct 2013 21:02:35 -  1.173
 +++ sbin/sysctl/sysctl.8  2 Mar 2014 18:45:29 -
 @@ -303,6 +303,7 @@ and a few require a kernel compiled with
  .It net.inet6.ip6.v6only Ta integer Ta no
  .It net.inet6.ip6.maxfrags Ta integer Ta yes
  .It net.inet6.ip6.mforwarding Ta integer Ta yes
 +.It net.inet6.ip6.mtudisctimeout Ta integer Ta yes
  .It net.inet6.ip6.multipath Ta integer Ta yes
  .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
  .It net.inet6.icmp6.rediraccept Ta integer Ta yes


 should be accompanied by a corresponding entry in sysctl(3), along with
 a description. i've no idea what this stuff does, and i'm not
 volunteering to go find out.

 i notice there's a few of the ip6 sysctls not documented...

which ipv6 sysctls are you referring to ?


 jmc




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

2014-03-03 Thread Loganaden Velvindron
On Mon, Mar 3, 2014 at 7:16 PM, Chris Cappuccio ch...@nmedia.net wrote:
 Loganaden Velvindron [logana...@gmail.com] wrote:

 That's OpenBSD -current right ? I'm going to test it in the afternoon,
 as the CDROM
 drive has issues on my OpenBSD development machine.


 Yes. The correct .fs images for testing are now the i386 and amd64 snapshot
 versions on the OpenBSD sites.

Hi Chris,

I followed your instructions, and it works fine. It loads the
installer, and there are no errors.
Tested on my OpenBSD dev box (AMD64) using a USB pendrive (2GB).

It's currently installing by fetching remote installation files. Would
you like a dmesg when the installation
is completed ?


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



sysctl.8: add missing mtudisctimeout for ipv6

2014-03-02 Thread Loganaden Velvindron
Hi,

While going through some of the commit logs, I noticed
that sysctl didn't list ip6.mtudisctimeout.

Patch attached:

Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.173
diff -u -p -u -p -r1.173 sysctl.8
--- sbin/sysctl/sysctl.828 Oct 2013 21:02:35 -  1.173
+++ sbin/sysctl/sysctl.82 Mar 2014 18:45:29 -
@@ -303,6 +303,7 @@ and a few require a kernel compiled with
 .It net.inet6.ip6.v6only Ta integer Ta no
 .It net.inet6.ip6.maxfrags Ta integer Ta yes
 .It net.inet6.ip6.mforwarding Ta integer Ta yes
+.It net.inet6.ip6.mtudisctimeout Ta integer Ta yes
 .It net.inet6.ip6.multipath Ta integer Ta yes
 .It net.inet6.ip6.multicast_mtudisc Ta integer Ta yes
 .It net.inet6.icmp6.rediraccept Ta integer Ta yes



Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED

2014-03-02 Thread Loganaden Velvindron
On Sat, Mar 1, 2014 at 7:59 AM, Chris Cappuccio ch...@nmedia.net wrote:
 Chris Cappuccio [ch...@nmedia.net] wrote:
 The installation entails:

 dd if=miniroot55.fs of=/dev/rsd2c


 Actually, for the install55.fs image, you want to specify a block size,
 (or wait ages.)

 dd if=install55.fs of=/dev/rsd2c bs=1m

 It's something like 20x faster to specify a block size on some of mine.

 The 512 byte default block size is so small, it must cause the USB key
 to re-write the same physical block multiple times. These devices have
 underlying blocks of 4K and larger.


That's OpenBSD -current right ? I'm going to test it in the afternoon,
as the CDROM
drive has issues on my OpenBSD development machine.




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Quirinus C library (qc)

2014-02-25 Thread Loganaden Velvindron
On Tue, Feb 25, 2014 at 3:39 PM, Dmitry Selyutin ghostman...@gmail.com wrote:
 Hello everyone!

 My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State
 University of Russia. This message is addressed mainly to C connoiseurs,
 yet I think other people may find it interesting. It's a GSoC proposal.
 First I've sent it to FreeBSD only since I didn't know that OpenBSD is
 accepted into GSoC too, so the rest is a copy of the original letter to
 FreeBSD mailing list with small changes.

Hi Dmitry !

Also, please have a look at the list of projects at
http://www.openbsdfoundation.org/gsoc2014.html


Since you like hacking on libs, have you considered looking at this
project and the SD/MMC stack project :
http://www.openbsdfoundation.org/gsoc2014.html#usb-userland-xfer

http://www.openbsdfoundation.org/gsoc2014.html#sdmmc

It's nice to have a suggestion, but please pay attention to the
_current_ problems that OpenBSD developers
are interested to solve. (Go through the tech archieves). If you find
something that you would like to solve, and it has been discussed
quite a few times on tech, I would suggest that you mail the developer
and ask for more information :-)

Good luck.


 It's a pity that for language like C we generally don't have something
 universal like Boost, so we have to implement some common functions from
 scratch or introduce new dependencies. We have Glib, which is used mainly
 by Gnome developers (though it is a standalone library) and LGPL-ed, which
 is not as liberal as Boost's license. We also have APR, which seems to be a
 bit more comprehensive and convenient, yet it is not so well-known as Glib.
 I'm in process of implementing a something like Boost for ANSI C (though I
 don't pretend this library to share Boost's comprehensiveness). Several
 ideas I find useful are:


 1. Strict and universal interface. Each function begins with qc_ prefix,
 followed by type if function is type-related. Most of types (except
 enum-typedef'ed ones) have three common functions (replace _type_ with the
 necessary type name, e.g. _bytes_):
   a. Constructor: void * qc_type_construct(void). Allocate object instance
 and initialize it to default value.
   b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory
 allocated for object and its members.
   c. Replicator: void * qc_type_replicate(void const * pointer). Replicate
 object, copying its data to new allocated object, i.e. clone.
 Most of types also have _import_ and _export_ functions, which allow to
 fill allocated object with the desired data (e.g. fill bytes instance from
 null-terminated char string) or export data to another type. Almost all
 enum-typedef'ed types also have _import_ and _export_ functions to retrieve
 a key value corresponding to string.

 2. Common and universal error type, qc_error. Such errors can be generated
 from errno values as well as from Windows API errors.
 Almost all functions from qc library except for the three common functions
 (constructor, destructor, replicator) return qc_error code and set specific
 qc_errno variable to this code.
 It is now possible to write such constructions:
   if (qc_bytes_import_str(bytes_instance, Hello, world!))
 qc_errormsg(qc_errno, error check);
 Global variable qc_errno is implemented in terms of multithreading
 applications, it is unique for every running thread.

 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs
 types for characters, where qc_byte has exactly 8-bit width and qc_ucs has
 exactly 32-bit width).
 Charsets are just enumeration, e.g. QC_ENCODING_UTF8,
 QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired
 encoding using qc_encoding_import. If encoding is known under several
 names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be
 returned for any of ASCII, iso-ir-6, ANSI_X3.4-1968, ISO646-US,
 etc. Register doesn't matter.
 Two new types, qc_bytes and qc_unicode are provided, in order to store
 binary and Unicode data. It is possible to store null characters inside
 such objects. It is similar to C++ string and C++ vector classes.

 4. Universal file system path type. It is possible to achieve
 cross-platformness using such path types, i.e. it is possible to make
 directories, links, symlinks, remove files, directories, etc. regardless of
 platform path API.

 5. i18n support must be embedded with qc library. Locales, timezones, day
 and months names, etc. must be provided too, in several forms if necessary.
 i18n functions work with qc_unicode type, so charset conversion problems
 won't exist.

 6. Multithreading support if platform permits it. On POSIX we use pthreads,
 on Windows we use its API for multithreading. I'm also thinking about green
 threads implementation. Thread local storage is already implemented, yet
 there is still a lot work to be done with threads, mutexes, etc.

 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm
 planning to switch to 

Trivial patch for ipv6

2014-02-12 Thread Loganaden Velvindron
Hi All,

based on a similar change from FreeBSD:

Change the return error from EACCES to EPERM as it is not a file.

Index: src/sys/netinet6/ip6_mroute.c
===
RCS file: /cvs/src/sys/netinet6/ip6_mroute.c,v
retrieving revision 1.67
diff -u -p -u -p -r1.67 ip6_mroute.c
--- src/sys/netinet6/ip6_mroute.c   11 Nov 2013 09:15:35 -  1.67
+++ src/sys/netinet6/ip6_mroute.c   12 Feb 2014 18:04:44 -
@@ -247,7 +247,7 @@ int
 ip6_mrouter_set(int cmd, struct socket *so, struct mbuf *m)
 {
if (cmd != MRT6_INIT  so != ip6_mrouter)
-   return (EACCES);
+   return (EPERM);
 
switch (cmd) {
case MRT6_INIT:



Re: signed packages

2014-01-22 Thread Loganaden Velvindron
On Fri, Jan 17, 2014 at 3:26 PM, Marc Espie es...@nerim.net wrote:
 It's probably time to talk about it.

 Yes, we are now distributing signed packages.  A lot of people have probably
 noticed because there was a key mismatch on at least one batch of signed
 packages.

 Obviously, we haven't finished testing yet.

 Don't read too much into that.  Signed packages just mean you can use
 an insecure medium, such as ftp, to download packages: if the key matches,
 it means the package hasn't been tampered with since it was signed.

 The cryptographic framework used to sign packages is called signify(1),
 mostly written by Ted Unangst, with a lot of feedback from (mostly) Theo
 and I.

 The signing framework in pkg_add/pkg_create is much older than that, if
 was written for x509 a few years ago, but signify(1) will probably be more
 robust and ways simpler.  In particular, there's no chain-of-trust, so
 you keep complete control on the sources YOU trust.

Can you please elborate more on the trusting part ?

Both DNSSEC and RPKI have a root anchor that we're all supposed to trust,
and your model is different.


 Signatures should be transparent in use: the package is opened, the
 packing-list signature is checked, and then files are checksummed while
 extracted against the packing-list embedded checksums (there are provisions
 to ensure any dangerous meta-data is also encoded in the packing-list as
 @mode/@user/@group annotations.

 So, barring problems, you shouldn't even notice signatures.




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: Request for Funding our Electricity

2014-01-14 Thread Loganaden Velvindron
On Wed, Jan 15, 2014 at 12:40 AM, Donald Allen donaldcal...@gmail.com wrote:
 On Tue, Jan 14, 2014 at 3:03 PM, Bob Beck b...@openbsdfoundation.org wrote:
Just to bring this issue back to the forefront.

 In light of shrinking funding, we do need to look for a source to
 cover project expenses.  If need be the OpenBSD Foundation can be
 involved in receiving donations to cover project electrical costs.

 But the fact is right now, OpenBSD will shut down if we do not have
 the funding to keep the lights on.

 If you or a company you know are able to assist us, it would be
 greatly appreciated, but right now we are looking at a significant
 funding shortfall for the upcoming year - Meaning the project won't be
 able to cover 20 thousand dollars in electrical expenses before being
 able to use money for other things. That sort of situation is not
 sustainable.

 There's an equation that has to be satisfied here. It has a demand
 side and a supply side. You demand a certain amount of electricity and
 someone has to supply the money to pay for it. I'm going to be blunt
 here, in an effort to be helpful (it's also not foreign to the OpenBSD
 style). I get the impression that the demand for electricity is viewed
 as a given:  you use what you use and people need to step up and
 provide the money to pay for it. If I'm wrong, please say so. But if
 I'm right, the demand can be adjusted. Sometimes you need to eat
 cornflakes instead of caviar. For example, I've never understood why
 this project supports the old architectures it does, considering the
 associated costs. The recent discussion of a need for a replacement
 Vax for package-building illustrates that.

 Perhaps this is an opportunity to reassess the scope of the project
 and trim some things that can no longer be justified on a cost-benefit
 basis.

 If the choice is between shutting the project down and reducing its
 scope to something sustainable, it's a no-brainer. This project has
 made really significant contributions, both in the obvious area,
 security, but also to the art of managing and building complex
 software that is reliable. To have it go away rather than trim its
 sails in way that acknowledges reality would really be a shame.

 /Don Allen


I'm not involved deeply in OpenBSD, but you'd be surprised at the
number of software that
incorporates OpenBSD improvements that you and I use.

If you run nsd or unbound:

(from nsd changelog)

Bugfixes:

Fix for accept spinning reported by OpenBSD.

OpenBSD security improvements are often submitted to other projects so
that everybody can benefit:

Fix bug where clear_remove() and clear_inodedeps() would not iterate
over the entire pagedep and inodedep hash tables due to an off-by-one
mistake in loops.  Spotted by and diff from Pedro Martelletto. Sent
upstream to Kirk and also fixed in FreeBSD.
ok otto@ millert@

These are just 2 examples that I picked, but there are many more.

OpenSSH wouldn't be reliable if it wasn't tested on HPPA and sparc64:

(I'm pretty sure I saw a bunch of commits wrt to alignment issues that
were discovered
on HPPA or sparc64 for OpenSSH).

If we re-view the project, we end up with OpenBSD not being able to
make continuous improvements to the whole
world as well as it is doing right now.

So let's do our best to allow the project to grow  :-) !





 On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt dera...@cvs.openbsd.org 
 wrote:
 I am resending this request for funding our electricity bills because
 it is not yet resolved.

 We really need even more funding beyond that, because otherwise all of
 this is simply unsustainable.  This request is the smallest we can
 make.

 ---

 Hi everyone.

 The OpenBSD project uses a lot of electricity for running the
 development and build machines.  A number of logistical reasons
 prevents us from moving the machines to another location which might
 offer space/power for free, so let's not allow the conversation to go
 that way.

 We are looking for a Canadian company who will take on our electrical
 expenses -- on their books, rather than on our books.  We would be
 happiest to find someone who will do this on an annual recurring
 basis.

 That way the various OpenBSD efforts can be supported, yet written off
 as an off-site operations cost by such a company.  If we reduce this
 cost, it will leave more money for other parts of the project.

 We think that a Canadian company is the best choice for accounting
 reasons.  If a company in some other jurisdiction feels they can also
 do this successfully, we'd be very happy to hear from them as well.

 I am not going to disclose the actual numbers here.  Please contact me
 for details if serious.

 Thanks.





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



whois close fd patch

2014-01-03 Thread Loganaden Velvindron
Hi All,

From NetBSD:
Coverity CID 1736

Close fd sfo  sfi before returning from whois(). 

whois() is called from within a loop before exiting.

for (name = *argv; (name = *argv) != NULL; argv++)
rval += whois(name, host ? host : choose_server(name, country),
port_whois, flags);
exit(rval);



Index: src/usr.bin/whois/whois.c
===
RCS file: /cvs/src/usr.bin/whois/whois.c,v
retrieving revision 1.45
diff -u -p -r1.45 whois.c
--- src/usr.bin/whois/whois.c   25 Nov 2013 18:06:32 -  1.45
+++ src/usr.bin/whois/whois.c   1 Jan 2014 10:59:12 -
@@ -260,6 +260,8 @@ whois(const char *query, const char *ser
free(nhost);
}
freeaddrinfo(res);
+   (void)fclose(sfi);
+   (void)fclose(sfo);
return (error);
 }



fgen free alias in error path

2013-12-30 Thread Loganaden Velvindron
Hi All,

From NetBSD:
Coverity CID 1748: Free alias on error.


alias-name = strdup(token-text);
if (alias-name == NULL)
(void)err(1, out of memory);

token = yylex();
if (token == NULL) {
free(alias);
(void)printf( EOF in alias definition\n);
return;

alias-name calls strdup, but it doesn't free it on if (token == NULL).

Shouldn't it be free'ed as well ?

Index: src/usr.bin/fgen/fgen.l
===
RCS file: /cvs/src/usr.bin/fgen/fgen.l,v
retrieving revision 1.9
diff -u -p -r1.9 fgen.l
--- src/usr.bin/fgen/fgen.l 10 Dec 2009 17:31:49 -  1.9
+++ src/usr.bin/fgen/fgen.l 30 Dec 2013 08:03:10 -
@@ -1232,6 +1232,7 @@ tokenize(input) 

token = yylex();
if (token == NULL) {
+   free(alias-name);
free(alias);
(void)printf( EOF in alias definition\n);
return;



irc.mindcry.org down

2013-12-30 Thread Loganaden Velvindron
Hi All,

I can no longer find irc.mindcry.org on the internet.

Is that permanent or temporary ?

//logan
c-x-c-c



Re: column memory leak fix

2013-12-30 Thread Loganaden Velvindron
On Mon, Dec 30, 2013 at 12:45:47PM +0100, Mike Belopuhov wrote:
 On Sun, Dec 29, 2013 at 22:45 -0800, Loganaden Velvindron wrote:
  Hi All,
  
  From NetBSD:
  
  Plug memory leak. Coverity CID 1596
  
 
 memory leak?  can you please elaborate where else this memory
 is leaking if not back to the system.

After a short discussion on IRC, and some digging, it makes sense
that the system cleanups up automatically, and therefore it is not 
necessary.


 
  Index: src/usr.bin/column/column.c
  ===
  RCS file: /cvs/src/usr.bin/column/column.c,v
  retrieving revision 1.16
  diff -u -p -r1.16 column.c
  --- src/usr.bin/column/column.c 26 Nov 2013 13:18:55 -  1.16
  +++ src/usr.bin/column/column.c 30 Dec 2013 06:38:02 -
  @@ -241,6 +241,9 @@ maketbl(void)
  (void)printf(%s\n, t-list[coloff]);
  }
  }
  +   free(tbl);
  +   free(cols);
  +   free(lens);
   }
   
   #defineDEFNUM  1000
  



Re: column memory leak fix

2013-12-30 Thread Loganaden Velvindron
On Mon, Dec 30, 2013 at 08:42:00AM -0500, Ted Unangst wrote:
 On Mon, Dec 30, 2013 at 13:53, Mike Belopuhov wrote:
  On Mon, Dec 30, 2013 at 03:59 -0800, Loganaden Velvindron wrote:
  On Mon, Dec 30, 2013 at 12:45:47PM +0100, Mike Belopuhov wrote:
   On Sun, Dec 29, 2013 at 22:45 -0800, Loganaden Velvindron wrote:
Hi All,
   
From NetBSD:
   
Plug memory leak. Coverity CID 1596
   
  
   memory leak?  can you please elaborate where else this memory
   is leaking if not back to the system.
 
  After a short discussion on IRC, and some digging, it makes sense
  that the system cleanups up automatically, and therefore it is not
  necessary.
 
  
  the patch can be committed though for the sake of better style.
 
 but please review to make sure they are correct.

It would be great if the ldconfig, and the various maintainers could
review the diff, and help me improve the diffs, or discard them.

I'm mostly interested in finding the small security issues and fixing
them, rather than fixing style issues :-)



user(8) free() before returning in groupmod()

2013-12-30 Thread Loganaden Velvindron
From NetBSD:

Coverity annotation -- although memsave free()s its first argument, it
will allocate memory and assign it to its first argument, so it is neutral

Coverity CID 3228:  memory leak -- failed to free() newname in groupmod()

Index: src/usr.sbin/user/user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.98
diff -u -p -r1.98 user.c
--- src/usr.sbin/user/user.c23 Nov 2013 17:14:05 -  1.98
+++ src/usr.sbin/user/user.c30 Dec 2013 15:58:48 -
@@ -2230,7 +2230,8 @@ groupmod(int argc, char **argv)
cc = strlcat(buf, \n, sizeof(buf));
if (cc = sizeof(buf))
errx(EXIT_FAILURE, group `%s' entry too long, grp-gr_name);
-
+   if (newname != NULL)
+   free(newname);
openlog(groupmod, LOG_PID, LOG_USER);
if (!modify_gid(*argv, buf))
err(EXIT_FAILURE, can't change %s file, _PATH_GROUP);
 



Re: column memory leak fix

2013-12-30 Thread Loganaden Velvindron
On Mon, Dec 30, 2013 at 10:32 PM, patrick keshishian
sids...@boxsoft.com wrote:
 On Mon, Dec 30, 2013 at 04:58:50PM +0100, Mike Belopuhov wrote:
 On 30 December 2013 16:35, Loganaden Velvindron lo...@elandsys.com wrote:
  On Mon, Dec 30, 2013 at 08:42:00AM -0500, Ted Unangst wrote:
  On Mon, Dec 30, 2013 at 13:53, Mike Belopuhov wrote:
   On Mon, Dec 30, 2013 at 03:59 -0800, Loganaden Velvindron wrote:
   On Mon, Dec 30, 2013 at 12:45:47PM +0100, Mike Belopuhov wrote:
On Sun, Dec 29, 2013 at 22:45 -0800, Loganaden Velvindron wrote:
 Hi All,

 From NetBSD:

 Plug memory leak. Coverity CID 1596

   
memory leak?  can you please elaborate where else this memory
is leaking if not back to the system.
  
   After a short discussion on IRC, and some digging, it makes sense
   that the system cleanups up automatically, and therefore it is not
   necessary.
  
  
   the patch can be committed though for the sake of better style.
 
  but please review to make sure they are correct.
 
  It would be great if the ldconfig, and the various maintainers could
  review the diff, and help me improve the diffs, or discard them.
 

 but the same applies to the ldconfig fix.  buildhints is called right
 before exit.  there are no leaks there.  the only thing that can be
 improved is unlinking tmpfilenam.

 Maybe so, but ever since I've known of OpenBSD, it has always
 preached good coding practices and exemplified through its
 base source code. So why are you discouraging such fixes? You
 are almost saying that any non-daemon program should not bother
 with free(), close() and similar resource de-allocation function,
 because the system will do the reclaiming after program exits.
 That's rubbish.

Hi Patrick, the base source code is pretty huge, and I'm sure that there are
memory/fd leak issues lurking around that need to be fixed. I'd much rather
spend time finding and fixing them :-)

After I got feedback on my diffs, I looked at another base program (user(8)) and
asked jj@ to have a look at the diff I just sent.

Let the developers decide what they think is the right way. Until they
reach consensus,
we can use our limited time to fix maximum number of bugs for OpenBSD
5.5 release :-)



 Regards,
 --patrick

  I'm mostly interested in finding the small security issues and fixing
  them, rather than fixing style issues :-)
 





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



restore(8) fd leak fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD:
Fix fd leak. Found by cppcheck

Index: src/sbin/restore/symtab.c
===
RCS file: /cvs/src/sbin/restore/symtab.c,v
retrieving revision 1.20
diff -u -p -r1.20 symtab.c
--- src/sbin/restore/symtab.c   24 Apr 2013 13:46:29 -  1.20
+++ src/sbin/restore/symtab.c   29 Dec 2013 11:37:28 -
@@ -553,6 +553,7 @@ initsymtable(char *filename)
warn(read);
panic(cannot read symbol table file %s\n, filename);
}
+   (void)close(fd);
switch (command) {
case 'r':
/*



ldconfig fd leak fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD:
Fix file descriptor leak. Found by cppcheck. 

Index: src/libexec/ld.so/ldconfig/ldconfig.c
===
RCS file: /cvs/src/libexec/ld.so/ldconfig/ldconfig.c,v
retrieving revision 1.31
diff -u -p -r1.31 ldconfig.c
--- src/libexec/ld.so/ldconfig/ldconfig.c   13 Nov 2013 05:41:42 -  
1.31
+++ src/libexec/ld.so/ldconfig/ldconfig.c   29 Dec 2013 11:53:38 -
@@ -416,16 +416,16 @@ buildhints(void)
if (write(fd, hdr, sizeof(struct hints_header)) !=
sizeof(struct hints_header)) {
warn(%s, _PATH_LD_HINTS);
-   goto out;
+   goto fdout;
}
if (write(fd, blist, hdr.hh_nbucket * sizeof(struct hints_bucket)) !=
hdr.hh_nbucket * sizeof(struct hints_bucket)) {
warn(%s, _PATH_LD_HINTS);
-   goto out;
+   goto fdout;
}
if (write(fd, strtab, strtab_sz) != strtab_sz) {
warn(%s, _PATH_LD_HINTS);
-   goto out;
+   goto fdout;
}
if (close(fd) != 0) {
warn(%s, _PATH_LD_HINTS);
@@ -438,6 +438,8 @@ buildhints(void)
}
 
ret = 0;
+fdout:
+   (void)close(fd);
 out:
free(blist);
free(strtab);



lpr fd leak fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD:

Fix fd leak in error cases. Found by cppcheck.

Index: cmds.c
===
RCS file: /cvs/src/usr.sbin/lpr/lpc/cmds.c,v
Index: cmds.c
===
RCS file: /cvs/src/usr.sbin/lpr/lpc/cmds.c,v
retrieving revision 1.25
diff -u -p -r1.25 cmds.c
--- cmds.c  24 Nov 2013 21:32:32 -  1.25
+++ cmds.c  29 Dec 2013 12:12:49 -
@@ -594,6 +594,8 @@ putmsg(int argc, char **argv)
if (fd  0 || flock(fd, LOCK_EX)  0) {
printf(\tcannot create status file\n);
PRIV_END;
+   if (fd = 0)
+   (void)close(fd);
return;
}
PRIV_END;



Re: lpr fd leak fix

2013-12-29 Thread Loganaden Velvindron
Diff got garbled.

Re-sending it:

Index: cmds.c
===
RCS file: /cvs/src/usr.sbin/lpr/lpc/cmds.c,v
retrieving revision 1.25
diff -u -p -r1.25 cmds.c
--- cmds.c  24 Nov 2013 21:32:32 -  1.25
+++ cmds.c  29 Dec 2013 12:12:49 -
@@ -594,6 +594,8 @@ putmsg(int argc, char **argv)
if (fd  0 || flock(fd, LOCK_EX)  0) {
printf(\tcannot create status file\n);
PRIV_END;
+   if (fd = 0)
+   (void)close(fd);
return;
}
PRIV_END;



Re: ldconfig fd leak fix

2013-12-29 Thread Loganaden Velvindron
On Sun, Dec 29, 2013 at 09:51:28AM -0800, patrick keshishian wrote:
 Hi,
 
 Accidentally deleted this message from my inbox. This is
 a reconstruction from mailing list archive.
 
 Suggestion/comment below.
 
 Earlier today:
  Hi All,
  
  From NetBSD:
  Fix file descriptor leak. Found by cppcheck. 
  
  Index: src/libexec/ld.so/ldconfig/ldconfig.c
  ===
  RCS file: /cvs/src/libexec/ld.so/ldconfig/ldconfig.c,v
  retrieving revision 1.31
  diff -u -p -r1.31 ldconfig.c
  --- src/libexec/ld.so/ldconfig/ldconfig.c   13 Nov 2013 05:41:42 -  
  1.31
  +++ src/libexec/ld.so/ldconfig/ldconfig.c   29 Dec 2013 11:53:38 -
  @@ -416,16 +416,16 @@ buildhints(void)
  if (write(fd, hdr, sizeof(struct hints_header)) !=
  sizeof(struct hints_header)) {
  warn(%s, _PATH_LD_HINTS);
  -   goto out;
  +   goto fdout;
  }
  if (write(fd, blist, hdr.hh_nbucket * sizeof(struct hints_bucket)) !=
  hdr.hh_nbucket * sizeof(struct hints_bucket)) {
  warn(%s, _PATH_LD_HINTS);
  -   goto out;
  +   goto fdout;
  }
  if (write(fd, strtab, strtab_sz) != strtab_sz) {
  warn(%s, _PATH_LD_HINTS);
  -   goto out;
  +   goto fdout;
  }
  if (close(fd) != 0) {
  warn(%s, _PATH_LD_HINTS);
  @@ -438,6 +438,8 @@ buildhints(void)
  }
   
  ret = 0;
  +fdout:
  +   (void)close(fd);
   out:
  free(blist);
  free(strtab);
  
 
 Why not a simpler diff where the the close() call is moved
 after 'out:' label instead of introducing a new label and
 an additional close() call?

That's equally possible.
 I adapted the diff from the NetBSD fix, which uses the additional
label.

I guess that it will boil down to the ldconfig maintainer to decide
which way is better :-)

 
 
 Like such:
 (disclaimer: not tested, not even compiled.)
 
 Index: ldconfig.c
 ===
 RCS file: /cvs/obsd/src/libexec/ld.so/ldconfig/ldconfig.c,v
 retrieving revision 1.31
 diff -u -p -u -p -r1.31 ldconfig.c
 --- ldconfig.c13 Nov 2013 05:41:42 -  1.31
 +++ ldconfig.c29 Dec 2013 15:31:58 -
 @@ -322,7 +322,7 @@ hinthash(char *cp, int vmajor, int vmino
  int
  buildhints(void)
  {
 - int strtab_sz = 0, nhints = 0, fd, i, ret = -1, str_index = 0;
 + int strtab_sz = 0, nhints = 0, fd = -1, i, ret = -1, str_index = 0;
   struct hints_bucket *blist;
   struct hints_header hdr;
   struct shlib_list *shp;
 @@ -427,10 +427,6 @@ buildhints(void)
   warn(%s, _PATH_LD_HINTS);
   goto out;
   }
 - if (close(fd) != 0) {
 - warn(%s, _PATH_LD_HINTS);
 - goto out;
 - }
  
   if (rename(tmpfilenam, _PATH_LD_HINTS) != 0) {
   warn(%s, _PATH_LD_HINTS);
 @@ -439,6 +435,8 @@ buildhints(void)
  
   ret = 0;
  out:
 + if (-1 != fd  close(fd) != 0)
 + warn(%s, _PATH_LD_HINTS);
   free(blist);
   free(strtab);
   return (ret);



user(8) fd fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD:
Close masterfd after reading from it. Found by cppcheck.


Index: src/usr.sbin/user/user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.98
diff -u -p -r1.98 user.c
--- src/usr.sbin/user/user.c23 Nov 2013 17:14:05 -  1.98
+++ src/usr.sbin/user/user.c29 Dec 2013 19:55:36 -
@@ -1014,6 +1014,7 @@ adduser(char *login_name, user_t *up)
pw_abort();
err(EXIT_FAILURE, read error on %s, _PATH_MASTERPASSWD);
}
+   (void)close(masterfd);
/* if no uid was specified, get next one in [low_uid..high_uid] range */
sync_uid_gid = (strcmp(up-u_primgrp, =uid) == 0);
if (up-u_uid == UID_MAX) {



pwd_mkdb fd leak fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD: fd leak fix, found by cppcheck.

Index: src/usr.sbin/pwd_mkdb/pwd_mkdb.c
===
RCS file: /cvs/src/usr.sbin/pwd_mkdb/pwd_mkdb.c,v
retrieving revision 1.43
diff -u -p -r1.43 pwd_mkdb.c
--- src/usr.sbin/pwd_mkdb/pwd_mkdb.c8 Jan 2010 13:29:08 -   1.43
+++ src/usr.sbin/pwd_mkdb/pwd_mkdb.c29 Dec 2013 20:11:34 -
@@ -375,8 +375,10 @@ cp(char *from, char *to, mode_t mode)
 
if ((from_fd = open(from, O_RDONLY, 0))  0)
error(from);
-   if ((to_fd = open(to, O_WRONLY|O_CREAT|O_EXCL, mode))  0)
+   if ((to_fd = open(to, O_WRONLY|O_CREAT|O_EXCL, mode))  0) {
+   (void)close(from_fd);
error(to);
+   }
while ((rcount = read(from_fd, buf, MAXBSIZE))  0) {
wcount = write(to_fd, buf, rcount);
if (rcount != wcount || wcount == -1) {



Re: user(8) fd fix

2013-12-29 Thread Loganaden Velvindron
On Sun, Dec 29, 2013 at 03:19:08PM -0500, Ted Unangst wrote:
 On Sun, Dec 29, 2013 at 11:59, Loganaden Velvindron wrote:
  Hi All,
  
  From NetBSD:
  Close masterfd after reading from it. Found by cppcheck.
 
 This is wrong.
 
  Proper code using fdopen() with error checking should close(2) fildes in
  case of failure, and fclose(3) the resulting FILE * in case of success.

You're right ! I just checked the man page.

 
  
  
  Index: src/usr.sbin/user/user.c
  ===
  RCS file: /cvs/src/usr.sbin/user/user.c,v
  retrieving revision 1.98
  diff -u -p -r1.98 user.c
  --- src/usr.sbin/user/user.c23 Nov 2013 17:14:05 -  1.98
  +++ src/usr.sbin/user/user.c29 Dec 2013 19:55:36 -
  @@ -1014,6 +1014,7 @@ adduser(char *login_name, user_t *up)
  pw_abort();
  err(EXIT_FAILURE, read error on %s, _PATH_MASTERPASSWD);
  }
  +   (void)close(masterfd);
  /* if no uid was specified, get next one in [low_uid..high_uid] range */
  sync_uid_gid = (strcmp(up-u_primgrp, =uid) == 0);
  if (up-u_uid == UID_MAX) {



column memory leak fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD:

Plug memory leak. Coverity CID 1596

Index: src/usr.bin/column/column.c
===
RCS file: /cvs/src/usr.bin/column/column.c,v
retrieving revision 1.16
diff -u -p -r1.16 column.c
--- src/usr.bin/column/column.c 26 Nov 2013 13:18:55 -  1.16
+++ src/usr.bin/column/column.c 30 Dec 2013 06:38:02 -
@@ -241,6 +241,9 @@ maketbl(void)
(void)printf(%s\n, t-list[coloff]);
}
}
+   free(tbl);
+   free(cols);
+   free(lens);
 }
 
 #defineDEFNUM  1000



cmp fd leak fix

2013-12-29 Thread Loganaden Velvindron
Hi All,

From NetBSD:

Plug fd leak. Coverity CID 1624.

Index: src/usr.bin/cmp/special.c
===
RCS file: /cvs/src/usr.bin/cmp/special.c,v
retrieving revision 1.7
diff -u -p -r1.7 special.c
--- src/usr.bin/cmp/special.c   19 Jan 2011 13:01:25 -  1.7
+++ src/usr.bin/cmp/special.c   30 Dec 2013 06:54:05 -
@@ -88,6 +88,8 @@ eof:  if (ferror(fp1))
} else
if (feof(fp2))
eofmsg(file2);
+   (void)fclose(fp1);
+   (void)fclose(fp2);
if (dfound)
exit(DIFF_EXIT);
 }



mke2fs.c memory leak

2013-12-24 Thread Loganaden Velvindron
From NetBSD:

free(bbp) in error paths.  Coverity CID 274748.

Index: src/sbin/newfs_ext2fs/mke2fs.c
===
RCS file: /cvs/src/sbin/newfs_ext2fs/mke2fs.c,v
retrieving revision 1.5
diff -u -p -r1.5 mke2fs.c
--- src/sbin/newfs_ext2fs/mke2fs.c  17 Apr 2013 03:33:13 -  1.5
+++ src/sbin/newfs_ext2fs/mke2fs.c  25 Dec 2013 05:52:25 -
@@ -1262,8 +1262,10 @@ alloc(uint32_t size, uint16_t mode)
 #endif
 
loc = skpc(~0U, len, bbp);
-   if (loc == 0)
+   if (loc == 0) {
+   free(bbp);
return 0;
+   }
loc = len - loc;
map = bbp[loc];
bno = loc * NBBY;
@@ -1271,6 +1273,7 @@ alloc(uint32_t size, uint16_t mode)
if ((map  (1  i)) == 0)
goto gotit;
}
+   free(bbp);
return 0;

  gotit:



rnd.c small space diff

2013-12-22 Thread Loganaden Velvindron
Hi,

While peeking into rnd.c, I can across a tiny style issue.

Index: src/sys/dev/rnd.c
===
RCS file: /cvs/src/sys/dev/rnd.c,v
retrieving revision 1.148
diff -u -p -r1.148 rnd.c
--- src/sys/dev/rnd.c   11 Dec 2013 19:34:11 -  1.148
+++ src/sys/dev/rnd.c   22 Dec 2013 07:15:19 -
@@ -612,7 +612,7 @@ static inline void
 _rs_rekey(u_char *dat, size_t datlen)
 {
 #ifndef KEYSTREAM_ONLY
-   memset(rs_buf, 0,RSBUFSZ);
+   memset(rs_buf, 0, RSBUFSZ);
 #endif
/* fill rs_buf with the keystream */
chacha_encrypt_bytes(rs, rs_buf, rs_buf, RSBUFSZ);



Re: txp(4) 3Com 3XP Typhoon/Sidewinder diff needs testing

2013-12-02 Thread Loganaden Velvindron
On Mon, Dec 2, 2013 at 4:36 PM, Mike Belopuhov m...@belopuhov.com wrote:
 On 2 December 2013 03:07, Brad Smith b...@comstyle.com wrote:
 Here is a diff for the txp(4) 3Com 3XP Typhoon/Sidewinder driver to clean up
 and update the receive filter / ioctl handling code to be in line with the
 other drivers.

 Anyone with hw and able to test? OK?


 as long as you're just moving stuff around, it should be fine.
 i doubt you'll find people with such ancient and rather rare
 hardware.

I have a bunch of adapters that brad mentioned.

Give me some hours, I'm setting up my gear.



 i might have also missed why are you doing that.  is it to have
 if_iff and call all this stuff from the ether_ioctl?




-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: IPv6 routing header type 0

2013-11-14 Thread Loganaden Velvindron
On Thu, Nov 14, 2013 at 4:27 AM, Alexander Bluhm
alexander.bl...@gmx.net wrote:
 On Fri, Oct 18, 2013 at 08:45:02PM +0200, Alexander Bluhm wrote:
 Our IPv6 stack scans all extension headers for routing header type
 0 and drops the packet if it finds one.  RFC 5095 demands to handle
 a routing header type 0 like an unrecognised routing type.  This
 is enough to protect the own machine.

 To protect a network as a firewall, we have pf which does the same
 full scan in pf_walk_header6().  As pf is enabled by default, nothing
 changes for most users.  If you turn off pf on your router, you
 should not expect extra protection.

 I would like to get rid of the double scanning and the old disabled
 code in the IPv6 stack.

 Theo and others don't like that change as it decreases security.
 There are hosts out there that still process RH0 and there are
 OpenBSD routers with pf disabled.

 This diff brings back the header chain scanning.  As an improvement
 it only scans if pf has not done that before.

 Note that ip6_check_rh0hdr() can be easily tricked by hiding the
 routing header type 0 behind a fragment header.  Only pf can protect
 you correctly as it reassembles on the forwarding path.  So I am
 not sure wether it is worth adding it again.

 Comments?

I guess it would help people who decide to disable pf for slight
performance benefit ?



 bluhm

 Index: net/pf.c
 ===
 RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
 retrieving revision 1.857
 diff -u -p -u -p -r1.857 pf.c
 --- net/pf.c30 Oct 2013 11:35:10 -  1.857
 +++ net/pf.c13 Nov 2013 23:14:32 -
 @@ -6490,6 +6490,7 @@ pf_test(sa_family_t af, int fwdir, struc
 }
 }
 pd.eh = eh;
 +   pd.m-m_pkthdr.pf.flags |= PF_TAG_PROCESSED;

 switch (pd.virtual_proto) {

 Index: netinet6/ip6_input.c
 ===
 RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/ip6_input.c,v
 retrieving revision 1.120
 diff -u -p -u -p -r1.120 ip6_input.c
 --- netinet6/ip6_input.c11 Nov 2013 09:15:35 -  1.120
 +++ netinet6/ip6_input.c13 Nov 2013 23:38:22 -
 @@ -122,6 +122,7 @@ struct ifqueue ip6intrq;
  struct ip6stat ip6stat;

  void ip6_init2(void *);
 +int ip6_check_rh0hdr(struct mbuf *, int *);

  int ip6_hopopts_input(u_int32_t *, u_int32_t *, struct mbuf **, int *);
  struct mbuf *ip6_pullexthdr(struct mbuf *, size_t, int);
 @@ -331,6 +332,20 @@ ip6_input(struct mbuf *m)
 srcrt = !IN6_ARE_ADDR_EQUAL(odst, ip6-ip6_dst);
  #endif

 +   /*
 +* Be more secure than RFC5095 and scan for type 0 routing headers.
 +* If pf has already scanned the header chain, do not do it twice.
 +*/
 +   if (!(m-m_pkthdr.pf.flags  PF_TAG_PROCESSED) 
 +   ip6_check_rh0hdr(m, off)) {
 +   ip6stat.ip6s_badoptions++;
 +   in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_discard);
 +   in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_hdrerr);
 +   icmp6_error(m, ICMP6_PARAM_PROB, ICMP6_PARAMPROB_HEADER, off);
 +   /* m is already freed */
 +   return;
 +   }
 +
 if (IN6_IS_ADDR_LOOPBACK(ip6-ip6_src) ||
 IN6_IS_ADDR_LOOPBACK(ip6-ip6_dst)) {
 ours = 1;
 @@ -698,6 +713,74 @@ ip6_input(struct mbuf *m)
 return;
   bad:
 m_freem(m);
 +}
 +
 +/* scan packet for RH0 routing header. Mostly stolen from pf.c:pf_test() */
 +int
 +ip6_check_rh0hdr(struct mbuf *m, int *offp)
 +{
 +   struct ip6_hdr *ip6 = mtod(m, struct ip6_hdr *);
 +   struct ip6_rthdr rthdr;
 +   struct ip6_ext opt6;
 +   u_int8_t proto = ip6-ip6_nxt;
 +   int done = 0, lim, off, rh_cnt = 0;
 +
 +   off = ((caddr_t)ip6 - m-m_data) + sizeof(struct ip6_hdr);
 +   lim = min(m-m_pkthdr.len, ntohs(ip6-ip6_plen) + sizeof(*ip6));
 +   do {
 +   switch (proto) {
 +   case IPPROTO_ROUTING:
 +   *offp = off;
 +   if (rh_cnt++) {
 +   /* more then one rh header present */
 +   return (1);
 +   }
 +
 +   if (off + sizeof(rthdr)  lim) {
 +   /* packet to short to make sense */
 +   return (1);
 +   }
 +
 +   m_copydata(m, off, sizeof(rthdr), (caddr_t)rthdr);
 +
 +   if (rthdr.ip6r_type == IPV6_RTHDR_TYPE_0) {
 +   *offp += offsetof(struct ip6_rthdr, 
 ip6r_type);
 +   return (1);
 +   }
 +
 +   off += (rthdr.ip6r_len + 1) * 8;
 +   proto = rthdr.ip6r_nxt;
 +   break;
 +   case IPPROTO_AH:
 +   case IPPROTO_HOPOPTS:
 +   

Re: IPv6 routing header type 0

2013-11-14 Thread Loganaden Velvindron
On Thu, Nov 14, 2013 at 10:04 PM, Mike Belopuhov m...@belopuhov.com wrote:
 On 14 November 2013 18:52, Henning Brauer lists-openbsdt...@bsws.de wrote:
 * Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 18:47]:
  it is the status quo *right now*

 Look, you can't call something the status quo when a commit was made 1
 month ago, to a REAL status quo that existed for 10 years when itojun
 made the change...  and immediately after this recent commit we
 started arguying about the change.

 Go find out what status quo means.

 let's not get into this, leads us nowhere.

   It *was* being filtered, until a month ago.
  no news here - we had discussed that change at the time. pretty sure
  you were in the loop even.
 No, I was not in the loop before it was commited, and many others were
 not either.  Apparently only you and mikeb were, and you did NOT push
 for more people to know about the change before it was commited.

 mikeb? bluhm worked on  comitted that otoh.
 i'm still pretty damn sure you were Cc'd; won't dig for old mail just
 to prove it; don't see the point, doesn't change anything now anyway.


 we have discussed that with bluhm in berlin and initially i had the same
 opinion: leave the check in the stack, but he has convinced me that it's
 rather pf's job to do it.  i'm not against bringing it back and his diff
 looks fine to me, esp. since it avoids double check that was there before.

Personally, I wasn't aware that variations of RH0 attacks are
possible, and that PF is the only
way to mitigate the attacks completely, until alexender blumh mentioned.

To me, that  is an important piece of information for end-users
running v6 networks.

Do you guys think that it might be worth mentioning this in pfctl man page ?

Index: src/sbin/pfctl/pfctl.8
===
RCS file: /cvs/src/sbin/pfctl/pfctl.8,v
retrieving revision 1.163
diff -u -p -r1.163 pfctl.8
--- src/sbin/pfctl/pfctl.8  21 Jul 2013 17:22:49 -  1.163
+++ src/sbin/pfctl/pfctl.8  14 Nov 2013 20:03:46 -
@@ -175,6 +175,9 @@ Overrides the definition of
 in the ruleset.
 .It Fl d
 Disable the packet filter.
+
+This disables advanced protection against Routing Type 0 attacks as the network
+stack only has a basic protection solution to Routing Type 0 vulnerability.
 .It Fl e
 Enable the packet filter.
 .It Fl F Ar modifier



 The non-pf RH0 filtering case is worthwhile.

 and here we disagree.

 --
 Henning Brauer, h...@bsws.de, henn...@openbsd.org
 BS Web Services GmbH, http://bsws.de, Full-Service ISP
 Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully 
 Managed
 Henning Brauer Consulting, http://henningbrauer.com/





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



ip6_mroute.c m_free() - m_freem()

2013-10-04 Thread Loganaden Velvindron
Hi,

I came across this small diff in netbsd. It fixes a small case of mbuf
leak possibility.

Index: sys/netinet6/ip6_mroute.c
===
RCS file: /cvs/src/sys/netinet6/ip6_mroute.c,v
retrieving revision 1.62
diff -u -p -r1.62 ip6_mroute.c
--- sys/netinet6/ip6_mroute.c   31 May 2013 15:04:24 -  1.62
+++ sys/netinet6/ip6_mroute.c   4 Oct 2013 07:04:50 -
@@ -503,7 +503,7 @@ ip6_mrouter_done(void)
for (rte = rt-mf6c_stall; rte != NULL; ) {
struct rtdetq *n = rte-next;
 
-   m_free(rte-m);
+   m_freem(rte-m);
free(rte, M_MRTABLE);
rte = n;
}



[lists-openbsdt...@bsws.de: Re: ip6_mroute.c m_free() - m_freem()]

2013-10-04 Thread Loganaden Velvindron
- Forwarded message from Henning Brauer lists-openbsdt...@bsws.de -

Date: Fri, 4 Oct 2013 13:34:26 +0200
From: Henning Brauer lists-openbsdt...@bsws.de
To: Loganaden Velvindron lo...@elandsys.com
Subject: Re: ip6_mroute.c m_free() - m_freem()
User-Agent: Mutt/1.5.21 (2010-09-15)

ok

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

- End forwarded message -



Re: Multicast macros and global list of addresses

2013-10-01 Thread Loganaden Velvindron
On Tue, Oct 1, 2013 at 3:33 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
 On 19/09/13(Thu) 13:59, Martin Pieuchot wrote:
 Diff below change the macros used to iterate over the multicast
 records linked to an interface without using the global lists of
 addresses.

 These records are currently link to the first address descriptor,
 respectively v4 and v6, even if they are per-interface.  So I
 changed the code to loop over the global interface list instead
 of iterating over all existing addresses.

 Tested here with a carp setup.  Comments, ok?

What kind of test coverage are you looking for specifically ?



 I got one ok for this diff but no other feedback.

 Did somebody tried it on a different setup?  I would really help me to
 get this in to move forward, so I appreciate any tests, reviews or ok.

 Index: netinet/igmp.c
 ===
 RCS file: /home/ncvs/src/sys/netinet/igmp.c,v
 retrieving revision 1.33
 diff -u -p -r1.33 igmp.c
 --- netinet/igmp.c2 May 2013 11:54:10 -   1.33
 +++ netinet/igmp.c13 Sep 2013 09:07:42 -
 @@ -104,6 +104,7 @@ int   igmp_timers_are_running;
  static struct router_info *rti_head;
  struct igmpstat igmpstat;

 +void igmp_checktimer(struct ifnet *);
  void igmp_sendpkt(struct in_multi *, int, in_addr_t);
  int rti_fill(struct in_multi *);
  struct router_info * rti_find(struct ifnet *);
 @@ -193,7 +194,6 @@ igmp_input(struct mbuf *m, ...)
   int igmplen;
   int minlen;
   struct in_multi *inm;
 - struct in_multistep step;
   struct router_info *rti;
   struct in_ifaddr *ia;
   int timer;
 @@ -266,17 +266,14 @@ igmp_input(struct mbuf *m, ...)
* except those that are already running and those
* that belong to a local group (224.0.0.X).
*/
 - IN_FIRST_MULTI(step, inm);
 - while (inm != NULL) {
 - if (inm-inm_ia-ia_ifp == ifp 
 - inm-inm_timer == 0 
 + IN_FOREACH_MULTI(ia, ifp, inm) {
 + if (inm-inm_timer == 0 
   !IN_LOCAL_GROUP(inm-inm_addr.s_addr)) {
   inm-inm_state = IGMP_DELAYING_MEMBER;
   inm-inm_timer = IGMP_RANDOM_DELAY(
   IGMP_MAX_HOST_REPORT_DELAY * 
 PR_FASTHZ);
   igmp_timers_are_running = 1;
   }
 - IN_NEXT_MULTI(step, inm);
   }
   } else {
   if (!IN_MULTICAST(ip-ip_dst.s_addr)) {
 @@ -297,10 +294,8 @@ igmp_input(struct mbuf *m, ...)
* timers already running, check if they need to be
* reset.
*/
 - IN_FIRST_MULTI(step, inm);
 - while (inm != NULL) {
 - if (inm-inm_ia-ia_ifp == ifp 
 - !IN_LOCAL_GROUP(inm-inm_addr.s_addr) 
 + IN_FOREACH_MULTI(ia, ifp, inm) {
 + if (!IN_LOCAL_GROUP(inm-inm_addr.s_addr) 
   (ip-ip_dst.s_addr == 
 INADDR_ALLHOSTS_GROUP ||
ip-ip_dst.s_addr == 
 inm-inm_addr.s_addr)) {
   switch (inm-inm_state) {
 @@ -323,7 +318,6 @@ igmp_input(struct mbuf *m, ...)
   break;
   }
   }
 - IN_NEXT_MULTI(step, inm);
   }
   }

 @@ -505,8 +499,7 @@ igmp_leavegroup(struct in_multi *inm)
  void
  igmp_fasttimo(void)
  {
 - struct in_multi *inm;
 - struct in_multistep step;
 + struct ifnet *ifp;
   int s;

   /*
 @@ -518,8 +511,21 @@ igmp_fasttimo(void)

   s = splsoftnet();
   igmp_timers_are_running = 0;
 - IN_FIRST_MULTI(step, inm);
 - while (inm != NULL) {
 + TAILQ_FOREACH(ifp, ifnet, if_list)
 + igmp_checktimer(ifp);
 + splx(s);
 +}
 +
 +
 +void
 +igmp_checktimer(struct ifnet *ifp)
 +{
 + struct in_multi *inm;
 + struct in_ifaddr *ia;
 +
 + splsoftassert(IPL_SOFTNET);
 +
 + IN_FOREACH_MULTI(ia, ifp, inm) {
   if (inm-inm_timer == 0) {
   /* do nothing */
   } else if (--inm-inm_timer == 0) {
 @@ -535,9 +541,7 @@ igmp_fasttimo(void)
   } else {
   igmp_timers_are_running = 1;
   }
 - IN_NEXT_MULTI(step, inm);
   }
 - splx(s);
  }

  void
 Index: netinet/in_var.h
 ===
 RCS file: /home/ncvs/src/sys/netinet/in_var.h,v

Re: openbsd ioctl fix (in6.c)

2013-09-30 Thread Loganaden Velvindron
On Mon, Sep 30, 2013 at 10:51:47PM +0200, Alexander Bluhm wrote:
 On Wed, Sep 18, 2013 at 12:01:10AM -0700, Loganaden Velvindron wrote:
  Index: in6.c
  ===
  RCS file: /cvs/src/sys/netinet6/in6.c,v
  retrieving revision 1.118
  diff -u -p -r1.118 in6.c
  --- in6.c   26 Aug 2013 07:15:58 -  1.118
  +++ in6.c   18 Sep 2013 06:54:13 -
  @@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm
  sa6 = ifr-ifr_addr;
  break;
  case SIOCSIFADDR:
  +   case SIOCSIFDSTADDR:
  +   case SIOCSIFBRDADDR:
  +   case SIOCSIFNETMASK:
  /*
  -* Do not pass this ioctl to driver handler since it is not
  +* Do not pass those ioctl to driver handler since they are 
  not
   * properly setup. Instead just error out.
   */
  return (EOPNOTSUPP);
 
 This diff uses spaces instead of tabs.  Please use tabs to make
 diffs apply cleanly.
 
 The errno EAFNOSUPPORT Address family not supported by protocol
 family is more specific for that error, at least if_ppp and if_sl
 use that.

Fixed style issues:

Index: netinet6/in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.118
diff -u -p -r1.118 in6.c
--- netinet6/in6.c  26 Aug 2013 07:15:58 -  1.118
+++ netinet6/in6.c  30 Sep 2013 21:14:43 -
@@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm
sa6 = ifr-ifr_addr;
break;
case SIOCSIFADDR:
+   case SIOCSIFDSTADDR:
+   case SIOCSIFBRDADDR:
+   case SIOCSIFNETMASK:
/*
-* Do not pass this ioctl to driver handler since it is not
+* Do not pass those ioctl to driver handler since they are not
 * properly setup. Instead just error out.
 */
return (EOPNOTSUPP);

 
 anyway, code is correct, OK bluhm@

Can you please elaborate a bit concerning the cleanup for if_tun.c that
mpi@ mentioned ?



Re: openbsd ioctl fix (in6.c)

2013-09-26 Thread Loganaden Velvindron
ping ?

On Wed, Sep 18, 2013 at 11:01 AM, Loganaden Velvindron
lo...@elandsys.com wrote:
 On Tue, Aug 27, 2013 at 10:37:30AM +0200, Martin Pieuchot wrote:
 On 22/08/13(Thu) 23:31, Claudio Jeker wrote:
  On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote:
   I'm not sure if applies to OpenBSD as well, but NetBSD
   also disallowed SIOCSIFDSTADDR for ioctl.
   [...]
  
   Index: sys/netinet6/in6.c
   ===
   RCS file: /cvs/src/sys/netinet6/in6.c,v
   retrieving revision 1.117
   diff -u -p -r1.117 in6.c
   --- sys/netinet6/in6.c13 Aug 2013 05:52:25 -  1.117
   +++ sys/netinet6/in6.c21 Aug 2013 15:50:00 -
   @@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm
 sa6 = ifr-ifr_addr;
 break;
 case SIOCSIFADDR:
   + case SIOCSIFDSTADDR:
 /*
   -  * Do not pass this ioctl to driver handler since it is not
   +  * Do not pass those ioctl to driver handler since they are not
  * properly setup. Instead just error out.
  */
 return (EOPNOTSUPP);
 
  Are any of our driver ioctl handlers handling SIOCSIFDSTADDR? I don't
  think so but I think this could be just extra safety and should therefor
  be commited.

 Only tun(4) seems to have some code for it, but I don't think it is
 correct.  And if it is, we should probably use SIOCGIFDSTADDR_IN6
 anyway.

 Maybe a small cleanup can be done?

 So I'm also in favor of this supplementary safety check, and I
 would even add SIOCSIFBRDADDR to this list.

 And SIOCSIFNETMASK as well to be safe ?

 Index: in6.c
 ===
 RCS file: /cvs/src/sys/netinet6/in6.c,v
 retrieving revision 1.118
 diff -u -p -r1.118 in6.c
 --- in6.c   26 Aug 2013 07:15:58 -  1.118
 +++ in6.c   18 Sep 2013 06:54:13 -
 @@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm
 sa6 = ifr-ifr_addr;
 break;
 case SIOCSIFADDR:
 +   case SIOCSIFDSTADDR:
 +   case SIOCSIFBRDADDR:
 +   case SIOCSIFNETMASK:
 /*
 -* Do not pass this ioctl to driver handler since it is not
 +* Do not pass those ioctl to driver handler since they are 
 not
  * properly setup. Instead just error out.
  */
 return (EOPNOTSUPP);

 M.





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: openbsd ioctl fix (in6.c)

2013-09-18 Thread Loganaden Velvindron
On Tue, Aug 27, 2013 at 10:37:30AM +0200, Martin Pieuchot wrote:
 On 22/08/13(Thu) 23:31, Claudio Jeker wrote:
  On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote:
   I'm not sure if applies to OpenBSD as well, but NetBSD
   also disallowed SIOCSIFDSTADDR for ioctl.
   [...]
   
   Index: sys/netinet6/in6.c
   ===
   RCS file: /cvs/src/sys/netinet6/in6.c,v
   retrieving revision 1.117
   diff -u -p -r1.117 in6.c
   --- sys/netinet6/in6.c13 Aug 2013 05:52:25 -  1.117
   +++ sys/netinet6/in6.c21 Aug 2013 15:50:00 -
   @@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm
 sa6 = ifr-ifr_addr;
 break;
 case SIOCSIFADDR:
   + case SIOCSIFDSTADDR:
 /*
   -  * Do not pass this ioctl to driver handler since it is not
   +  * Do not pass those ioctl to driver handler since they are not
  * properly setup. Instead just error out.
  */
 return (EOPNOTSUPP);
   
  Are any of our driver ioctl handlers handling SIOCSIFDSTADDR? I don't
  think so but I think this could be just extra safety and should therefor
  be commited.
 
 Only tun(4) seems to have some code for it, but I don't think it is
 correct.  And if it is, we should probably use SIOCGIFDSTADDR_IN6
 anyway.
 
 Maybe a small cleanup can be done?
 
 So I'm also in favor of this supplementary safety check, and I
 would even add SIOCSIFBRDADDR to this list.

And SIOCSIFNETMASK as well to be safe ?

Index: in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.118
diff -u -p -r1.118 in6.c
--- in6.c   26 Aug 2013 07:15:58 -  1.118
+++ in6.c   18 Sep 2013 06:54:13 -
@@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm
sa6 = ifr-ifr_addr;
break;
case SIOCSIFADDR:
+   case SIOCSIFDSTADDR:
+   case SIOCSIFBRDADDR:
+   case SIOCSIFNETMASK:
/*
-* Do not pass this ioctl to driver handler since it is not
+* Do not pass those ioctl to driver handler since they are not
 * properly setup. Instead just error out.
 */
return (EOPNOTSUPP);
 
 M.
 



Re: openbsd ioctl fix (in6.c)

2013-08-27 Thread Loganaden Velvindron
On Tue, Aug 27, 2013 at 10:37:30AM +0200, Martin Pieuchot wrote:
 On 22/08/13(Thu) 23:31, Claudio Jeker wrote:
  On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote:
   I'm not sure if applies to OpenBSD as well, but NetBSD
   also disallowed SIOCSIFDSTADDR for ioctl.
   [...]
   
   Index: sys/netinet6/in6.c
   ===
   RCS file: /cvs/src/sys/netinet6/in6.c,v
   retrieving revision 1.117
   diff -u -p -r1.117 in6.c
   --- sys/netinet6/in6.c13 Aug 2013 05:52:25 -  1.117
   +++ sys/netinet6/in6.c21 Aug 2013 15:50:00 -
   @@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm
 sa6 = ifr-ifr_addr;
 break;
 case SIOCSIFADDR:
   + case SIOCSIFDSTADDR:
 /*
   -  * Do not pass this ioctl to driver handler since it is not
   +  * Do not pass those ioctl to driver handler since they are not
  * properly setup. Instead just error out.
  */
 return (EOPNOTSUPP);
   
  Are any of our driver ioctl handlers handling SIOCSIFDSTADDR? I don't
  think so but I think this could be just extra safety and should therefor
  be commited.
 
 Only tun(4) seems to have some code for it, but I don't think it is
 correct.  And if it is, we should probably use SIOCGIFDSTADDR_IN6
 anyway.
 
 Maybe a small cleanup can be done?
I haven't looked at tun(4) code yet, but I can give it a try :-)

 
 So I'm also in favor of this supplementary safety check, and I
 would even add SIOCSIFBRDADDR to this list.
I'm updating the diff.

 
 M.
 



udp6 fix for possible memory corruption

2013-08-23 Thread Loganaden Velvindron
Hi,

From NetBSD:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/udp6_output.c?rev=1.41content-type=text/x-cvsweb-markuponly_with_tag=MAIN

Under some circumstances, udp6_output() would call ip6_clearpktopts()
with an uninitialized struct ip6_pktopts on the stack, opt.
ip6_clearpktopts(opt, ...) could dereference dangling pointers,
leading to memory corruption or a crash.  Now, udp6_output() calls
ip6_clearpktopts(opt, ...) only if opt was initialized. Thanks to
Clement LECIGNE for reporting this bug.

I checked openbsd source code and it seems that the issue is present
as well.

Tentative diff:

Index: udp6_output.c
===
RCS file: /cvs/src/sys/netinet6/udp6_output.c,v
retrieving revision 1.19
diff -u -p -r1.19 udp6_output.c
--- udp6_output.c   28 Mar 2013 16:45:16 -  1.19
+++ udp6_output.c   23 Aug 2013 19:30:36 -
@@ -119,7 +119,8 @@ udp6_output(struct in6pcb *in6p, struct 
struct  in6_addr *laddr, *faddr;
u_short fport;
int error = 0;
-   struct ip6_pktopts *optp, opt;
+   struct ip6_pktopts *optp = NULL; 
+   struct ip6_pktopts opt;
int priv;
int af, hlen;
int flags;
@@ -284,7 +285,8 @@ release:
 
 releaseopt:
if (control) {
-   ip6_clearpktopts(opt, -1);
+   if (optp == opt)
+   ip6_clearpktopts(opt, -1);
m_freem(control);
}
return (error);



ipv6 atomic draft - rfc6946 diff

2013-08-22 Thread Loganaden Velvindron
Hi,

The draft is now an RFC.
Perhaps the code should reflect those changes as well ?


Index: sys/netinet6/frag6.c
===
RCS file: /cvs/src/sys/netinet6/frag6.c,v
retrieving revision 1.47
diff -u -p -r1.47 frag6.c
--- sys/netinet6/frag6.c11 Jun 2013 18:15:54 -  1.47
+++ sys/netinet6/frag6.c22 Aug 2013 06:36:35 -
@@ -236,7 +236,7 @@ frag6_input(struct mbuf **mp, int *offp,
offset += sizeof(struct ip6_frag);
 
/*
-* draft-gont-6man-ipv6-atomic-fragments-00:  A host that receives an
+* RFC6946:  A host that receives an
 * IPv6 packet which includes a Fragment Header with the Fragment
 * Offset equal to 0 and the M bit equal to 0 MUST process such
 * packet in isolation from any other packets/fragments.



Re: ipv6 atomic draft - rfc6946 diff

2013-08-22 Thread Loganaden Velvindron
On Thu, Aug 22, 2013 at 08:53:50AM +0200, Peter Hessler wrote:
 Have you verified that we follow the RFC, and not just -00 of the draft?
 
The table of OSes were updated and some terms were changed:

   A host that receives an IPv6 packet that includes a Fragment
  Header with the Fragment Offset equal to 0 and the M flag
  equal to 0 MUST process that packet in isolation from any other
  packets/fragments, even if such packets/fragments contain the same
  set {IPv6 Source Address, IPv6 Destination Address, Fragment
  Identification}.  A received atomic fragment should be
  reassembled from the contents of that sole fragment.
bit-flag, and some clarifications added.



 On 2013 Aug 21 (Wed) at 23:40:12 -0700 (-0700), Loganaden Velvindron wrote:
 :Hi,
 :
 :The draft is now an RFC.
 :Perhaps the code should reflect those changes as well ?
 :
 :
 :Index: sys/netinet6/frag6.c
 :===
 :RCS file: /cvs/src/sys/netinet6/frag6.c,v
 :retrieving revision 1.47
 :diff -u -p -r1.47 frag6.c
 :--- sys/netinet6/frag6.c11 Jun 2013 18:15:54 -  1.47
 :+++ sys/netinet6/frag6.c22 Aug 2013 06:36:35 -
 :@@ -236,7 +236,7 @@ frag6_input(struct mbuf **mp, int *offp,
 :offset += sizeof(struct ip6_frag);
 : 
 :/*
 :-* draft-gont-6man-ipv6-atomic-fragments-00:  A host that receives an
 :+* RFC6946:  A host that receives an
 : * IPv6 packet which includes a Fragment Header with the Fragment
 : * Offset equal to 0 and the M bit equal to 0 MUST process such
 : * packet in isolation from any other packets/fragments.
 :
 
 -- 
 It's better to be wanted for murder than not to be wanted at all.
   -- Marty Winch



openbsd ioctl fix (in6.c)

2013-08-21 Thread Loganaden Velvindron
I'm not sure if applies to OpenBSD as well, but NetBSD
also disallowed SIOCSIFDSTADDR for ioctl.

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/in6.c?annotate=1.166only_with_tag=MAIN

1.2   itojun374:switch (cmd) {
1.104 christos  375:/*
1.105 christos  376: * XXX: Fix me, once we fix SIOCSIFADDR, 
SIOCIFDSTADDR, etc.
1.104 christos  377: */
378:case SIOCSIFADDR:
1.105 christos  379:case SIOCSIFDSTADDR:
1.129 cube  380: #ifdef SIOCSIFCONF_X25
1.106 christos  381:case SIOCSIFCONF_X25:
1.110 matt  382: #endif
1.104 christos  383:return EOPNOTSUPP;

If it's indeed the case in OpenBSD, here's a diff:

Index: sys/netinet6/in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.117
diff -u -p -r1.117 in6.c
--- sys/netinet6/in6.c  13 Aug 2013 05:52:25 -  1.117
+++ sys/netinet6/in6.c  21 Aug 2013 15:50:00 -
@@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm
sa6 = ifr-ifr_addr;
break;
case SIOCSIFADDR:
+   case SIOCSIFDSTADDR:
/*
-* Do not pass this ioctl to driver handler since it is not
+* Do not pass those ioctl to driver handler since they are not
 * properly setup. Instead just error out.
 */
return (EOPNOTSUPP);



Re: OpenBSD in6 ioctl fix

2013-08-21 Thread Loganaden Velvindron
On Wed, Aug 21, 2013 at 8:05 PM, Loganaden Velvindron
lo...@elandsys.com wrote:
 It appears that SIOCSIFDSTADDR should not be allowed
 upon an AF_INET6 socket as well.


 From netbsd:
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/in6.c?annotate=1.166only_with_tag=MAIN

 1.2   itojun374:switch (cmd) {
 1.104 christos  375:/*
 1.105 christos  376: * XXX: Fix me, once we fix SIOCSIFADDR, 
 SIOCIFDSTADDR, etc.
 1.104 christos  377: */
 378:case SIOCSIFADDR:
 1.105 christos  379:case SIOCSIFDSTADDR:
 1.129 cube  380: #ifdef SIOCSIFCONF_X25
 1.106 christos  381:case SIOCSIFCONF_X25:
 1.110 matt  382: #endif
 1.104 christos  383:return EOPNOTSUPP;

 diff:
 Index: sys/netinet6/in6.c
 ===
 RCS file: /cvs/src/sys/netinet6/in6.c,v
 retrieving revision 1.117
 diff -u -p -r1.117 in6.c
 --- sys/netinet6/in6.c  13 Aug 2013 05:52:25 -  1.117
 +++ sys/netinet6/in6.c  21 Aug 2013 15:50:00 -
 @@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm
 sa6 = ifr-ifr_addr;
 break;
 case SIOCSIFADDR:
 +   case SIOCSIFDSTADDR:
 /*
 -* Do not pass this ioctl to driver handler since it is not
 +* Do not pass those ioctl to driver handler since they are 
 not
  * properly setup. Instead just error out.
  */
 return (EOPNOTSUPP);


Sorry for double-posting. please disregard this mail.


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



OpenBSD in6 ioctl fix

2013-08-21 Thread Loganaden Velvindron
It appears that SIOCSIFDSTADDR should not be allowed
upon an AF_INET6 socket as well.


From netbsd:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/in6.c?annotate=1.166only_with_tag=MAIN

1.2   itojun374:switch (cmd) {
1.104 christos  375:/*
1.105 christos  376: * XXX: Fix me, once we fix SIOCSIFADDR, 
SIOCIFDSTADDR, etc.
1.104 christos  377: */
378:case SIOCSIFADDR:
1.105 christos  379:case SIOCSIFDSTADDR:
1.129 cube  380: #ifdef SIOCSIFCONF_X25
1.106 christos  381:case SIOCSIFCONF_X25:
1.110 matt  382: #endif
1.104 christos  383:return EOPNOTSUPP;

diff:
Index: sys/netinet6/in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.117
diff -u -p -r1.117 in6.c
--- sys/netinet6/in6.c  13 Aug 2013 05:52:25 -  1.117
+++ sys/netinet6/in6.c  21 Aug 2013 15:50:00 -
@@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm
sa6 = ifr-ifr_addr;
break;
case SIOCSIFADDR:
+   case SIOCSIFDSTADDR:
/*
-* Do not pass this ioctl to driver handler since it is not
+* Do not pass those ioctl to driver handler since they are not
 * properly setup. Instead just error out.
 */
return (EOPNOTSUPP);



Re: goodbye to some isa devices

2013-03-26 Thread Loganaden Velvindron
On Tue, Mar 26, 2013 at 5:09 PM, Ted Unangst t...@tedunangst.com wrote:
 On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
 Date: Tue, 26 Mar 2013 05:20:27 -0400
 From: Ted Unangst t...@tedunangst.com

 These isa devs are already disabled and not particularly popular among
 our users.  affected: tcic, sea, wds, eg, el

 The reason these devices are disabled is probably that their probe
 routines are destructive.  So the fact that they are disabled doesn't
 necessarily mean that they don't work properly.

 I don't think maintaining these drivers is currently a huge burden on
 us.  But decoupling them from the build will almost certainly lead to
 some degree of bitrot.

 Perfection is achieved when there's nothing left to take away. :)

 It's not so much that we spend time maintaining the source, but I do
 spend time compiling it. And I have to download it (3 times!) every
 time I install a new snapshot. Cumulatively, I've probably spent hours
 of my life waiting for these drivers' bits to go from here to there. I
 will selfishly claim that if I save five minutes of time this year by
 not compiling these files, that right there is more benefit than
 retaining support.

 I targeted disabled devices figuring they were least likely to be
 missed, but I honestly question the utility of any of these ISA
 network and SCSI drivers. They're going to be slow as shit. Besides,
 at this point, due to adding so many new drivers (kernel size has
 more than doubled in last ten years) the minimum RAM requirement is
 basically past ISA only machines. The segment of machines that lack
 PCI but support 32M or more of RAM is very narrow. And unlike sparc or
 vax, I don't think running OpenBSD on some ancient 486 is historically
 interesting.


I still run OpenBSD as a wireless AP on a pentium-1 166Mhz with 48Mb RAM, and
3 PCI cards. ISA sound card was removed :-)



-- 
Brightest day,
Blackest night,
No bug shall escape my sight,
And those who worship evil's mind,
be wary of my powers,
puffy lantern's light !



Re: mg: don't spin when stdin is lost

2013-01-21 Thread Loganaden Velvindron
On Mon, Jan 14, 2013 at 9:16 PM, Florian Obser flor...@openbsd.org wrote:

 this can be tested like this:
 EDITOR=mg cvs commit
 kill cvs
 - mg spins with 100% cpu in ttgetc

 Might be related to what I saw a few times. When I detached screen or
tmux,
and go back, cpu would shoot to 100%.


 While there prevent an unterminated recursion in panic (via ttclose).
 I'm not particularly happy with the errorhandling in ttgetc, but this
 is the least intrusive change.

 comments, oks?

 diff --git ttyio.c ttyio.c
 index 228a370..5b9021f 100644
 --- ttyio.c
 +++ ttyio.c
 @@ -173,7 +173,9 @@ ttgetc(void)
 redraw(0, 0);
 winch_flag = 0;
 }
 -   } else if (ret == 1)
 +   } else if (ret == -1  errno == EIO)
 +   panic(lost stdin);
 +   else if (ret == 1)
 break;
 } while (1);
 return ((int) c)  0xFF;
 @@ -196,6 +198,12 @@ charswaiting(void)
  void
  panic(char *s)
  {
 +   static int panicking = 0;
 +
 +   if (panicking)
 +   return;
 +   else
 +   panicking = 1;
 ttclose();
 (void) fputs(panic: , stderr);
 (void) fputs(s, stderr);

 --
 I'm not entirely sure you are real.




-- 
Brightest day,
Blackest night,
No bug shall escape my sight,
And those who worship evil's mind,
be wary of my powers,
puffy lantern's light !



Re: Goodbye to you my file descriptor

2012-11-03 Thread Loganaden Velvindron
Thanks for fixing my mistake :-)


On Sat, Nov 3, 2012 at 6:57 PM, Christiano F. Haesbaert
haesba...@haesbaert.org wrote:
 On Tue, Oct 30, 2012 at 04:44:36PM +0100, rustyBSD wrote:
 Le 30/10/2012 15:32, Christiano F. Haesbaert a ?crit :
  That should be an access(2) call.
 Yes.Something like this - also moved len to size_t,
 as strlen() is size_t:


 --- dired.cWed Mar 14 14:56:35 2012
 +++ dired.cTue Oct 30 16:23:00 2012
 @@ -724,9 +724,10 @@
  dired_(char *dname)
  {
  struct buffer*bp;
 -int len, i;
 +int i;
 +size_t len;

 -if ((fopen(dname,r)) == NULL) {
 +if (access(dname, R_OK) == -1) {
  if (errno == EACCES)
  ewprintf(Permission denied);
  return (NULL);


 Your diff got mangled, it replaced tabs for spaces, anyway, I think we
 should also check for X_OK, otherwise we can't list the directory
 anyway.

 We still get the message File is not readable, but I believe it's more
 useful than showing an empty directory.

 Index: dired.c
 ===
 RCS file: /cvs/src/usr.bin/mg/dired.c,v
 retrieving revision 1.51
 diff -d -u -p -r1.51 dired.c
 --- dired.c 14 Mar 2012 13:56:35 -  1.51
 +++ dired.c 3 Nov 2012 14:47:18 -
 @@ -724,9 +724,10 @@ struct buffer *
  dired_(char *dname)
  {
 struct buffer   *bp;
 -   int  len, i;
 +   int  i;
 +   size_t   len;

 -   if ((fopen(dname,r)) == NULL) {
 +   if ((access(dname, R_OK | X_OK)) == -1) {
 if (errno == EACCES)
 ewprintf(Permission denied);
 return (NULL);




-- 
Brightest day,
Blackest night,
No bug shall escape my sight,
And those who worship evil's mind,
be wary of my powers,
puffy lantern's light !



Re: Bringing some sanity to IPv6 traffic (IETF Internet-Drafts)

2012-10-20 Thread Loganaden Velvindron
Concerning the oversized-header-chain draft.

I'm still trying to wrap my head around ipv6 :-)

I was looking at the code and I thought of something like:

/*
 * If it's the 1st fragment, record the length of the
 * unfragmentable part and the next header of the fragment header.
 */
if (fragoff == 0) {
q6-ip6q_unfrglen = offset - sizeof(struct ip6_hdr) -
sizeof(struct ip6_frag);
/* make sure that the header chain is contained with
the first fragment */

if (q6-ip6q_unfrglen  IPV6_MMTU) {
  IP6Q_UNLOCK();
  return (IPPROTO_DONE);
}

If someone can help a bit, i can dig further :-)

On Tue, Oct 16, 2012 at 1:56 AM, Fernando Gont ferna...@gont.com.ar wrote:
 Folks,

 FYI:

 * http://tools.ietf.org/id/draft-ietf-6man-oversized-header-chain-01.txt
 * http://tools.ietf.org/id/draft-ietf-6man-nd-extension-headers-00.txt

 P.S.: These two have already been adopted by the 6man wg, and are close
 to publication as RFCs.

 Cheers,
 --
 Fernando Gont
 e-mail: ferna...@gont.com.ar || fg...@si6networks.com
 PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




-- 
Brightest day,
Blackest night,
No bug shall escape my sight,
And those who worship evil's mind,
be wary of my powers,
puffy lantern's light !



Another nsd vulnerability fix

2012-07-28 Thread Loganaden Velvindron
It can be triggered if nsd was compiled with --enable-zone-stats.

http://www.nlnetlabs.nl/downloads/CVE-2012-2979.txt

OpenBSD patch:

Index: query.c
===
RCS file: /cvs/src/usr.sbin/nsd/query.c,v
retrieving revision 1.6
diff -u -p -r1.6 query.c
--- query.c 19 Jul 2012 17:46:11 -  1.6
+++ query.c 28 Jul 2012 16:02:54 -
@@ -1209,9 +1209,11 @@ answer_query(struct nsd *nsd, struct que
answer_lookup_zone(nsd, q, answer, 0, exact, closest_match,
closest_encloser, q-qname);
 
-   ZTATUP2(q-zone, opcode, q-opcode);
-   ZTATUP2(q-zone, qtype, q-qtype);
-   ZTATUP2(q-zone, opcode, q-qclass);
+if (q-zone) {
+   ZTATUP2(q-zone, opcode, q-opcode);
+   ZTATUP2(q-zone, qtype, q-qtype);
+   ZTATUP2(q-zone, opcode, q-qclass);
+   }
 
offset = 
dname_label_offsets(q-qname)[domain_dname(closest_encloser)-label_count - 1] 
+ QHEADERSZ;
query_add_compression_domain(q, closest_encloser, offset);
@@ -1403,7 +1405,9 @@ query_add_optional(query_type *q, nsd_ty
}
ARCOUNT_SET(q-packet, ARCOUNT(q-packet) + 1);
STATUP(nsd, edns);
-   ZTATUP(q-zone, edns);
+   if (q-zone) {
+   ZTATUP(q-zone, edns);
+   }
break;
case EDNS_ERROR:
if (q-edns.dnssec_ok)  edns-error[7] = 0x80;
@@ -1412,7 +1416,9 @@ query_add_optional(query_type *q, nsd_ty
buffer_write(q-packet, edns-rdata_none, OPT_RDATA);
ARCOUNT_SET(q-packet, ARCOUNT(q-packet) + 1);
STATUP(nsd, ednserr);
-   ZTATUP(q-zone, ednserr);
+   if (q-zone) {
+   ZTATUP(q-zone, ednserr);
+   }
break;
}
 
Index: server.c
===
RCS file: /cvs/src/usr.sbin/nsd/server.c,v
retrieving revision 1.5
diff -u -p -r1.5 server.c
--- server.c9 Jul 2012 21:56:41 -   1.5
+++ server.c28 Jul 2012 16:02:55 -
@@ -1417,15 +1417,20 @@ handle_udp(netio_type *ATTR_UNUSED(netio
 #ifdef BIND8_STATS
if (RCODE(q-packet) == RCODE_OK  !AA(q-packet)) {
STATUP(data-nsd, nona);
-   ZTATUP(q-zone, nona);
+# ifdef USE_ZONE_STATS
+   if (q-zone)
+   ZTATUP(q-zone, nona);
+# endif
}
 
 # ifdef USE_ZONE_STATS
+   if (q-zone) {
if (data-socket-addr-ai_family == AF_INET) {
ZTATUP(q-zone, qudp);
} else if (data-socket-addr-ai_family == AF_INET6) {
ZTATUP(q-zone, qudp6);
}
+   }
 # endif
 #endif
 
@@ -1443,17 +1448,27 @@ handle_udp(netio_type *ATTR_UNUSED(netio
if (sent == -1) {
log_msg(LOG_ERR, sendto failed: %s, 
strerror(errno));
STATUP(data-nsd, txerr);
-   ZTATUP(q-zone, txerr);
+
+#ifdef USE_ZONE_STATS
+   if (q-zone)
+   ZTATUP(q-zone, txerr);
+#endif
} else if ((size_t) sent != 
buffer_remaining(q-packet)) {
log_msg(LOG_ERR, sent %d in place of %d 
bytes, sent, (int) buffer_remaining(q-packet));
 #ifdef BIND8_STATS
} else {
/* Account the rcode  TC... */
STATUP2(data-nsd, rcode, RCODE(q-packet));
-   ZTATUP2(q-zone, rcode, RCODE(q-packet));
+# ifdef USE_ZONE_STATS
+   if (q-zone)
+   ZTATUP2(q-zone, rcode, 
RCODE(q-packet));
+# endif
if (TC(q-packet)) {
STATUP(data-nsd, truncated);
-   ZTATUP(q-zone, truncated);
+# ifdef USE_ZONE_STATS
+   if (q-zone)
+   ZTATUP(q-zone, truncated);
+# endif
}
 #endif /* BIND8_STATS */
}
@@ -1665,12 +1680,16 @@ handle_tcp_reading(netio_type *netio,
 !AA(data-query-packet))
{
STATUP(data-nsd, nona);
-   ZTATUP(data-query-zone, nona);
+# ifdef USE_ZONE_STATS
+   if (data-query-zone)
+   ZTATUP(data-query-zone, nona);
+# endif
}
 
 # ifdef USE_ZONE_STATS
+   if (data-query-zone) {
 #  ifndef INET6
-   ZTATUP(data-query-zone, ctcp);
+   ZTATUP(data-query-zone, ctcp);
 #  else
 

  1   2   3   >