On Mon, Jul 07, 2014 at 08:25:25AM +0200, David Paleino wrote:
> On Sun, 6 Jul 2014 21:23:25 -0400, Theodore Ts'o wrote:
>
> > Do you have any objections if I upload this as a NMU? Or would you
> > prefer to update the package?
>
> Please Ted, go ahead. :)
Ok, thanks. I'll do that this evening. Since I got your ack, I won't
bother using a delayed queue.
BTW, I was looking at the local Debian patches, and with the exception
of the OUI list changes patch, I'm not convinced any of the other ones
make sense for us to be carrying.
In particular, 02-fix_usage_message.patch seems especially pointless,
since calling out that both "--mac=XX:XX:XX:XX:XX:XX" and "--mac
XX:XX:XX:XX:XX:XX" work is spectacularly pointless. That's a
fundamental feature of how getopt_long works, and if we really felt
the need to explicitly mention this fact for every single option that
takes an argument, the usage message for pretty much all of GNU shell
utils would grow by a huge amount.
Similarly, the chances that we might pick the same random mac address
is *possible*, but (a) it's so unlikely that it's not worth bothering
about, and (b) having the same MAC address get used once in a very
long while is actually a good thing.
In fact, growing the number of addresses in the OUI list is actually,
paradoxically, more likely to cause people to make MAC address stand
out as being more likely to be a spoofed address. Using a smaller
number of OUI's, but ones which are known to be commonly used by
modern systems, especially ones of the same type as the user (i.e., if
you are using a Thinkpad, you might want to use MAC addresses that are
used byThinkpads and Dell and HP laptops but if you use a MAC address
used by a medical device that would only be found in a hospital or
clinic, or research sensor, it might cause comment for that address to
show up at a Starbucks cafe).
Bottom line, keeping patches that are out of sync from upstream is
much more likely to cause harm than good.
Cheers,
- Ted
P.S. In fact, it looks like macchiato[1] is more advanced in terms of
actually providing security and privacy to its users, as opposed to
something that only *appears* to provide security.
[1] https://github.com/EtiennePerot/macchiato
So I'm wondering if it's better to package macchiato and then
encourage people to switch ot it, or to try to add macchiato's
features into macchanger. The advantage of the former is that it's
much less work. The advantage of the latter is that it's more likely
Debian users will benefit, since they won't have to switch their boot
scripts to use macchiato.
And of course, probably the best thing to do is that this
functionality should be built into network-manager. Where
network-manager really should be using random MAC addresses while it
is scanning for AP's, and depending on whether an AP (by MAC address)
is a "known" friendly one (i.e., when you are at your home router) or
one which is unknown (i.e., at a Starbucks cafe) it should
automatically randomize the MAC address before doing the DHCP dance....
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
