Re: 'IT Security' in comps?
On Fri, Aug 07, 2009 at 10:48:34AM -0400, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: 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. Rather than going back and forth about concepts, I might as well just describe how I would organize what you have now: network-debugging - Network Analysis Tools - Tools for analyzing and securing computer networks. (This would include the packages from both your proposed 'reconnaissance' and 'wireless' groups, as well as some other tools currently in 'System Tools'.) Imho most of these tools are more helpful to demonstrate security weaknesses, than to debug faulty networks. E.g. it is imho more reliable to run tcpdump on a host or to plugin a seperate hub, then to use ettercap to get to analyse the traffic in the network. Most of the tools are imho primarly useful to perform a penetration test and to demonstrate the security vulnerabilities for a customer. But in general a network-debugging group would be useful, too. forensics - Computer Forensic Tools - Tools for performing computer forensics and data recovery. (I'd move the password tools here, as well. Not sure how clamav fits here; I think its current placement at the mail server level makes more sense.) Password recovery tools do not really fit into the forensics group, too. If forensics are performed to analyse a security incidense, one normally does not need to recover passwords to get a timeline of what happened. It might be used as an interem step in forensics performed by the police to get to e.g. acquire the password of a encrypted volume, but then it would still not be the primary target of the forensic actions. The intrusion detection group looks OK as a concept. As for the code analysis group, I'd argue that should be moved into the development category. Is this something you'd find usable? It is more usable for me to have these groups than not to have these. But if I cannot easily install all these related groups, i.e. with one simple command, without the need to memorize all the separate groups, it is not useful enough for me, to put much work into it. Right now our toplevel groups are: - Language support (self explanatory) - Desktops (fairly self explanatory) - Applications (End-user desktop applications) - Development (tools for software development) - Servers (various system services) - Base system (administration tools, and other components) Perhaps a better solution is a new toplevel category of 'System Administration' (where most of your new groups would fall under); this widens the scope of it from just 'IT Security' to a larger scope that fits the existing categories. That might be a larger reorganization, though, as the group changes would have to filter down to the various spins. This sounds sane in general. - 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. Sure, but the live spin can do %group --optional to pull those in. To expand on what I said before, we have three main concepts for applying defaults in comps: - Lots of tools that occupy the same usage case (office tools, etc.) Pick one best-of-breed default, the rest are optional. - Lots of tools that occupy the same space, but are not interchangable. (games) Everything's optional. Pick what you want. - A basic usage case, with various add-ons and similar tools. (many of the server groups, 'system tools', etc.) A base set that's default; other tools are optional. Imho it is not that easy to apply this to security analysis. E.g. it is clear what one wants to do more or less with office tools: Writing documents. Then it does not matter that much, whether the GUI is developed for KDE or Gnome. But for a security analysis work, everything depends on the target network or system. It may and will normally differ in a lot of ways. Also since the tools may produce different results (e.g. forensic analysis tools), one would more likely use every tool to get as much results as possible, instead of only acquiring a subset of the available information. So to be prepared for these tasks, one needs more or less
Re: 'IT Security' in comps?
Till Maas (opensou...@till.name) said: 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. Rather than going back and forth about concepts, I might as well just describe how I would organize what you have now: network-debugging - Network Analysis Tools - Tools for analyzing and securing computer networks. (This would include the packages from both your proposed 'reconnaissance' and 'wireless' groups, as well as some other tools currently in 'System Tools'.) forensics - Computer Forensic Tools - Tools for performing computer forensics and data recovery. (I'd move the password tools here, as well. Not sure how clamav fits here; I think its current placement at the mail server level makes more sense.) The intrusion detection group looks OK as a concept. As for the code analysis group, I'd argue that should be moved into the development category. Is this something you'd find usable? 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. Right now our toplevel groups are: - Language support (self explanatory) - Desktops (fairly self explanatory) - Applications (End-user desktop applications) - Development (tools for software development) - Servers (various system services) - Base system (administration tools, and other components) Perhaps a better solution is a new toplevel category of 'System Administration' (where most of your new groups would fall under); this widens the scope of it from just 'IT Security' to a larger scope that fits the existing categories. That might be a larger reorganization, though, as the group changes would have to filter down to the various spins. - 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. Sure, but the live spin can do %group --optional to pull those in. To expand on what I said before, we have three main concepts for applying defaults in comps: - Lots of tools that occupy the same usage case (office tools, etc.) Pick one best-of-breed default, the rest are optional. - Lots of tools that occupy the same space, but are not interchangable. (games) Everything's optional. Pick what you want. - A basic usage case, with various add-ons and similar tools. (many of the server groups, 'system tools', etc.) A base set that's default; other tools are optional. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On 08/06/2009 02:37 AM, Till Maas wrote: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. That's not true. yum -v grouplist will display them. I use them all the time as a shorter form of the full group names. Something like # yum install @xfce-desktop Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
Till Maas (opensou...@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. 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. 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' 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. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Everyone on a multi user system can use the tool of his preference. ... So, the goal of this is for a multi-user forensic system, where you have multiple users working on the same system su-ing to root and running the tools of their choice? That's an odd usage case to design for by default. Also there may be a feature in one application, that is missing in another. Then fix one app so that it's reasonable enough. To quote Adam Jackson: Choice is not the goal. We have many interesting problems to solve and forcing the user to care about their choice of solutions is both bad UI and actively detracts from the real goal, which is making it work out of the box and enabling people to work on the really cool stuff at the edges. In comps, in most any group, the default item is the best-of-breed app; other implementations are optional. Btw. I fail to understand what trouble this is causing you. Thanks to bundling all together into one category, it will even disturb you less than six (or more) groups in some other category, where the stuff you are interested is. It's about not presenting bad UI and bad groups to our users - it's a design thing. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 01:24:24PM -0400, Bill Nottingham wrote: Till Maas (opensou...@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; 3) The description will be translated / meant to be human readable and not to be a machine readible property. 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. 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. 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. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Everyone on a multi user system can use the tool of his preference. ... So, the goal of this is for a multi-user forensic system, where you have multiple users working on the same system su-ing to root and running the tools of their choice? That's an odd usage case to design for by default. Afaics I did not mention the forensics group. I can't answer your questions if you refer to different groups with the group and then argue against the answer using some other group. The forensics group had 15 packages in it if I counted correclty and e.g. pdfresurect and chkrootkit are completely different applications. But how does searching for good or bad examples help here? Also there may be a feature in one application, that is missing in another. Then fix one app so that it's reasonable enough. To quote Adam Jackson: In reality, one does not very often have the time to first fix a bug, before a task can be completed. So this does not help me right now if I need to perform a task. Nevertheles the fixing can still be done later. Choice is not the goal. We have many interesting problems to solve and forcing the user to care about their choice of solutions is both bad UI and actively detracts from the real goal, which is making it work out of the box and enabling people to work on the really cool stuff at the edges. I do not know users who prefer to wait several days to months to perform a task with one application instead of doing it with another application. Especially not if the need to perform the task right now. In comps, in most any group, the default item is the best-of-breed app; other implementations are optional. I see, comps is not the right place to implement the feature that fulfills my need. Btw. I fail to understand what trouble this is causing you. Thanks to bundling all together into one category, it will even disturb you less than six (or more) groups in some other category, where the stuff you are interested is. It's about not presenting bad UI and bad groups to our users - it's a design thing. I do not agree that my groups are bad or that they are bad by their nature. Nevertheless, I do not see that this discussion is leading anywhere, that will allow to fulfill my needs (Easy installation of the software, easy finding of the software, allowing many people to do this and not maintaining the same information in several places) and your requests. Also it looks for me that you do not want these groups at any cost, because of the way you argue. In conclusion I have reverted the IT-security related changes to the
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 12:24:18PM +0530, Rahul Sundaram wrote: On 08/06/2009 02:37 AM, Till Maas wrote: The IT prefix is only used in the group id, which is afaik not visible to the used and not translated. That's not true. yum -v grouplist will display them. I use them all the time as a shorter form of the full group names. Something like # yum install @xfce-desktop Thanks, this is very helpful. Regards Till pgpmNwQUbTxST.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Thu, 6 Aug 2009, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: wireless group. Probably, but this cannot be done right now afaik. yum search certainly can be done now. the tag database that is being added to the pkgdb as a part of the Google Summer of Code is what yum will eventually be able to query as well. So you can return packages based on a number of arbitrary keywords/tags that, ultimately, can be set by users/contributors independent of the packager. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
On Thu, Aug 06, 2009 at 03:21:41PM -0400, Bill Nottingham wrote: Till Maas (opensou...@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
Re: 'IT Security' in comps?
On Wed, Aug 05, 2009 at 10:00:24AM -0400, Bill Nottingham wrote: Recently, you've added the following groups to comps: it-security-code-analysis it-security-forensics it-security-intrusion-detection it-security-reconnaissance it-security-wireless it-security-password-recovery You've also added a new toplevel category. This means this new nebulous 'IT Securty' item is pushed at the toplevel, much as 'Desktops' or 'Language Support'. That seems misplaced to me. How can I bundle the groups, if not with a category? Or can there be subcategories? While I know that we do allow some discretion in adding to comps, none of this was discussed beforehand on this list (that I saw), or in FESCo. These sorts of large scale changes are the sorts of things that should be discussed. I asked on this list and got a reply from Jesse Keating: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02292.html What is the overall goal of these changes? The goal is to make it easier to find software related to specific IT security related tasks. Why isn't this just done via a menus package in the security spin? Wouldn't that be more useful? No, because this does not help me with my search from yum. Btw. this is true for other package groups, too. E.g. we have a KDE spin and a KDE group in comps. Many of these packages are *already* in other groups; having them now be explicitly listed in multiple groups doesn't really make sense to me, especially when we already have 'Administration Tools' and 'System Tools' groups. I believe the restriction that packages may only belong to one group is gone. I don't see why it is not helpful to be easily able to install these related packages. Regards Till pgpA7FGLA0KUM.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: 'IT Security' in comps?
Till Maas (opensou...@till.name) said: You've also added a new toplevel category. This means this new nebulous 'IT Securty' item is pushed at the toplevel, much as 'Desktops' or 'Language Support'. That seems misplaced to me. How can I bundle the groups, if not with a category? Or can there be subcategories? I'm not sure they need to be bundled. Especially with 'IT' as a prefix; code analysis is code analysis; password recovery is password recovery. There's also ongoing work on package tagging that may fit better for more finer grained usages such as these. I asked on this list and got a reply from Jesse Keating: https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02292.html My mistake. Why isn't this just done via a menus package in the security spin? Wouldn't that be more useful? No, because this does not help me with my search from yum. 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. Btw. this is true for other package groups, too. E.g. we have a KDE spin and a KDE group in comps. Sure, but KDE is a much broader use case. I feel that the groups as you defined them are probably too fine grained. Moreover, what's the usage case in that you really need all three tools (which is the default if you install the group you mentioned)? Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
