[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kismet 2011.03.R2-1: Please review debconf PO/control for the package kismet

No actual proposed changes here, just chit-chat.

Nick Andrik wrote:
> Justin B Rye <jbr@edlug.org.uk>:
>> Do you mean "(Desktop) PCs" or "computers that are personal"?  Saying
>> "personal computers" makes it sound as if you *don't* mean to
>> include laptops (or palmtops and so on), but form factor isn't the
>> issue here; the question is just whether it's a single-user system.
> I mean personal (not multiuser) computers.
> BTW, I thought computers included laptops, but OK.

"Computers" certainly includes laptops; but "personal computers"
normally doesn't, because the term "PC" is only applied to stationary
home/workstation microcomputers in the tradition of the Intel PC, not
other sorts of hardware.  It gets even more confusing when people
start using "PC" to mean "Windows".  Sometimes people also distinguish
between "laptop" and "desktop" computers, but that's also a problem,
because these days an increasing proportion of so-called "laptops"
live permanently on top of desks, while workstation-class machines
tend to have a "tower" form-factor and live on the floor...

>> But what's unsafe about making it setuid on a multi-user system,
>> anyway?  Even if I don't trust my little brother, the argument
>> against "sudo kismet" is still valid, which implies that kismet
>> should still be installed with the setuid bit set - we should just
>> be warning against letting untrusted users in the kismet group!
> Agreed, I also cannot see why setuid with group permissions can be any
> insecure at all (or at least more insecure than ssudo), so maybe we
> could get the warning out?

I had:
>>  Enabling this feature allows users in the "kismet" group to run Kismet
>>  (and capture packets, change wireless card state, etc), so only thoroughly
>>  trusted users should be granted membership of the group.

You *could* drop the second half of this ("so only...").

>>> [...] "wireless sniffer and monitor". Do you think it'd be better?
>> I'm always cautious around the word "monitor", since of course it's
>> also a piece of hardware.  But maybe that does work.  Okay, why not.
>> (Oops, and I had left kismet-plugins with a capitalised synopsis;
>> fixed now.)
> We can keep the sniffer like this and change the monitor to monitoring?
> I don't have a problem for any case, I just what to convey the message

No, "wireless sniffer and monitoring" doesn't work.  Let's keep "and
>> Oh, I forgot to add my traditional Why The Name footnote.  README
>> §18 says: "I really just [...] clicked through a thesaurus until I
>> found a word that wasn't used in any other OSS projects".
> I understood nothing at all here, elaborate please :D

Here on debian-l10n-english I occasionally suggest that package
descriptions should mention the reason for the package's name (for
instance if it's a non-obvious acronym).  I've even produced a
spin-off Wiki page: "http://wiki.debian.org/WhyTheName";.  According to
the README, the answer in the case of Kismet is basically "why not?"
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

Reply to: