'IT Security' in comps?

[Till Maas]

On Thu, Aug 06, 2009 at 03:21:41PM -0400, Bill Nottingham wrote:
> Till Maas (opensource at till.name) said: 
> > > > The IT prefix is only used in the group id, which is afaik not visible
> > > > to the used and not translated.
> > > 
> > > No, it's not just in the description.
> > > 
> > > "These tools can be used to perform IT security related wireless auditing."
> > > 
> > > In this example, "IT security related" (aside from missing a hyphen
> > > or two) is completely superfluous.
> > 
> > 1) It is not a prefix in the description
> > 2) It does not allow easy selection of the packages, which was the
> > feature you said that it allows to have and which is the necessary
> > context you removed:
> > 
> > | I'm not sure they need to be bundled. Especially with 'IT' as a
> > | prefix;
> 
> Sorry, I should have expanded. It's bad to use the acronym at
> all.
> 
> > > > I don't understand what you want to say
> > > > with "password recovery" is "password recovery". There is nothing to
> > > > argue about, but nevertheles the groups are related to each other,
> > > 
> > > How so? aide is not really related to password recovery at all,
> > > at least not in any generally describable way.
> > 
> > So the assignement of tools to the groups can be improved. Does this
> > make the groups useless? I say no, there I don't see how this does
> > belong to this general discussion about whether or not there should be
> > these groups in comps.
> 
> You're stating that IT should be in the description as the groups
> are 'related'. I don't see how they're really that strongly related
> at all, and IT is superfluous information to the use case.

No, I did not state that, but maybe it was not obvious. I stated that
the groups should be put together. I agree that the "IT security" is not
needed in the password tools description and that the typo should be
fixed, it the term is used. I fail to understand why you think they are
not strongly related, they existence of the security spin proves that
they are imho. I considered IT might be redundant information, too, when
I created the groups, but also both the terms "Forensics" or "Wireless"
are not IT specific, therefore I put the IT-security explanation into
the description. There can be wireless analysis that is not security
related, e.g. to find sources of disturbance and there are a lot of
forensics tasks that are not IT-security related, but still could be
assisted via software. But I do not care that much to keep the term in
the description, this was just my motivation to put it there.

> > > > already expresses itself that they are all on the security spin. Also it
> > > > allows other people to easier ignore them, instead of cluttering other
> > > > categories.
> > > 
> > > Put it this way:
> > > 
> > > - These packages are all in other groups under 'Base System'
> > > - Ergo, if they're being grouped together, the resulting group
> > >   should still be under 'Base System'
> > 
> > It is not technically possible to have subgroups, as you can see in the
> > answer from Jesse Keating.
> 
> Additional groups under Base System, not sub-sub-groups.

This is no solution to grouping the packages together and still be able
to know which packages are for which sub group of tasks.

Btw. these tools to also not build a base system or at least what I
would think of a base system, because their use case is for certain
special tasks and does not form a base for other tools to build on, e.g.
cron performs a base set of features that can be used by other packages.
But this might not the criteria for packages in the base system
category.

> > > > > Tagging would help with this; as it stands now, 'yum search wireless'
> > > > > or 'yum search wireless sniffer' would return the packages in your
> > > > > wireless group.
> > > > 
> > > > Probably, but this cannot be done right now afaik.
> > > 
> > > yum search certainly can be done now.
> > 
> > Yes, but is there an easy search expression that will result with the
> > groups that I added? Afaik no. Does 'yum search wireless' returns 43
> > lines of packages, so it does not qualify.
> 
> # yum search wireless sniffer
> Loaded plugins: refresh-packagekit, verify
> ============================== Matched: sniffer, wireless
> ==============================
> aircrack-ng.x86_64 : 802.11 (wireless) sniffer and WEP/WPA-PSK key cracker
> kismet.x86_64 : WLAN detector, sniffer and IDS
> kismet-extras.x86_64 : Non-core programs for 'kismet'

I am impressed, I believe to have worse search experiences with yum
search. Nevertheless, airsnort is missing there, but on the other hand
kismet-extras is maybe missing in comps. But I do not currently know
whether or not comps is subpackage aware.

> My objections are:
> - the use of a toplevel category (they should be under the existing
>   categories)

This is addressed in my new proposal, they would be in no category or
can be in any existing category.

> - the excessive use of IT-security most everywhere, when it's not needed

I'm fine with removing it from the description, but I would like to keep
this or only security as a common prefix.

> - the potential explosion of small groups (long term, we need to make
>   tagging and searching work. Splitting into groups for every small
>   usage case doesn't scale.)

There are smaller groups currently in comps and the amount of packages
per group is not final, e.g. I already identified more packages that
would go into the wireless group and I already did not create a
anonymity group, which is used on the security live cd webpage, but
would only have two packages, that I know I would add to it.

> - the 'all packages are default' paradigm

I could accept to make packages not default that are e.g. already meant
to be deprecated by upstream, like airsnort. But I do not think that the
audience of these tools would only want to be presented some random
password cracker like it is a guideline to have only one IM client on
the Fedora Desktop live image. This is also reflected with the package
set of the security live image, which also contains all these tools and
not only selected ones.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090806/ddc27e93/attachment.bin