lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 02 Dec 2008 15:03:30 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	Benjamin.Thery@...l.net
Cc:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net: fix /proc/net/ip_mr_cache display

From: "Benjamin Thery " <Benjamin.Thery@...l.net>
Date: Mon, 01 Dec 2008 21:17:02 +0100

> The right way to fix it, IMHO, is to print 0 (zero) in the columns
> that have no meaning for the unresolved entries. That way we don't
> break the ABI: the userspace expects to get at least 6 numbers for
> each entries, it gets 6 numbers. It's easy to figure what zeros
> represent and this prevent people from wasting time trying to figure
> what to do with these "random" numbers on the unresolved entries, no?

Probably, this is correct.

However, we could run into problems if userland parsers expect
6 entries and then expect an immediate newline.  We'd break that.

The only thing that really works for extending files like this
is if they are already exporting a "key: value" interface, then
you can add new lines safely.

Doing this horizontal expansion as you are proposing here is,
on the other hand, very risky and dangerous.

I really don't think it's worth it.

Fix the garbage values, or flush them to zero if we can't
represent them properly.  But don't add new stuff horizontally
to "fill in the gaps", as I don't think it can be done %100
safely.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ