Is it such a big deal to have one normal local user account on your system? Are there any downsides to this? What if the NIS server dies, how will you login in an emergency?
I like the idea of not having root, and having only a local user setup with sudo rights in anaconda. Then if I really need the root account, I can do it in command line manually. In my opinion anaconda+firstboot should make life easier for people who don't know much about the system. If you're an advanced user, and really need a root user account, you should already have the knowledge how to create it in command line by yourself. You shouldn't need a GUI wizard for that.
--
Martin Gracik
----- "Steve Allen" allen@doobie.itdl.ds.boeing.com wrote:
M�ir�n Duffy duffy@fedoraproject.org wrote:
On Mon, 2010-11-22 at 17:45 +0000, Steve Allen wrote:
I already skip the creation of a local account, and set up NIS.
And yes,
I do want to set a root password.
I know you already skip it today, but you wouldn't be able to do
that in
Chris' original proposal I think. I can make sure in the redesign
that
we handle your case. Thanks!
And thank you for the consideration.
Steve
-- Steven R. Allen - Linux Admin Weenie Unix sysadmin: Linux, IRIX, NetBSD, OS X, Solaris, HP/UX, CX/UX Phone: 206-544-0910 M/S: 4J-06
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Martin Gracik mgracik@redhat.com wrote:
Is it such a big deal to have one normal local user account on your system? Are there any downsides to this? What if the NIS server dies, how will you login in an emergency?
I like the idea of not having root, and having only a local user setup with sudo rights in anaconda. Then if I really need the root account, I can do it in command line manually. In my opinion anaconda+firstboot should make life easier for people who don't know much about the system. If you're an advanced user, and really need a root user account, you should already have the knowledge how to create it in command line by yourself. You shouldn't need a GUI wizard for that.
I suspect that my situation is probably somewhat unconventional.
We're a lab, and deploy dozens of machines to do simulation tasks for various customers. It is easiest for me, as administrator, to log in to the various machines directly as root in order to do my work. I don't need a gui to set up the root account; in the past it has been sufficient to enter the root password as the system is being installed.
Being forced to make a (temporary) local account just to set up the root account is just adding that much more (in my view) unnecessary work.
Steve
I see, but what if you had a user "steve" with already setup sudo access for you, instead of the root account. Would that make your work more unpleasant?
Now you have to setup root account in the installer. So you have to setup at least one user account. The way I propose, you would still have to setup only one user, no more work on your side compared to the situation we have now. The user would just not be called root, but for example "steve".
Or is there some reason that you absolutely need root access?
--
Martin Gracik
----- "Steve Allen" allen@doobie.itdl.ds.boeing.com wrote:
Martin Gracik mgracik@redhat.com wrote:
Is it such a big deal to have one normal local user account on your
system? Are there
any downsides to this? What if the NIS server dies, how will you
login in an emergency?
I like the idea of not having root, and having only a local user
setup with sudo rights
in anaconda. Then if I really need the root account, I can do it in
command line manually.
In my opinion anaconda+firstboot should make life easier for people
who don't know much
about the system. If you're an advanced user, and really need a root
user account,
you should already have the knowledge how to create it in command
line by yourself.
You shouldn't need a GUI wizard for that.
I suspect that my situation is probably somewhat unconventional.
We're a lab, and deploy dozens of machines to do simulation tasks for various customers. It is easiest for me, as administrator, to log in to the various machines directly as root in order to do my work. I don't need a gui to set up the root account; in the past it has been sufficient to enter the root password as the system is being installed.
Being forced to make a (temporary) local account just to set up the root account is just adding that much more (in my view) unnecessary work.
Steve
-- Steven R. Allen - Linux Admin Weenie Unix sysadmin: Linux, IRIX, NetBSD, OS X, Solaris, HP/UX, CX/UX Phone: 206-544-0910 M/S: 4J-06
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Martin Gracik mgracik@redhat.com wrote:
I see, but what if you had a user "steve" with already setup sudo access for you, instead of the root account. Would that make your work more unpleasant?
In the sense that it is making extra work for me, yes. I would use the 'steve' account to set up the root account, then delete the 'steve' account.
Now you have to setup root account in the installer. So you have to setup at least one user account.
Root is a pre-existing account. All that is needed is to set a password for it.
The way I propose, you would still have to setup only one user, no more work on your side compared to the situation we have now. The user would just not be called root, but for example "steve".
Well, it would be more work for me -- see above. Admittedly, it's a one-time ten minute task to deal with, but multiply that by dozens of machines...
Or is there some reason that you absolutely need root access?
A significant number of people subscribe to the "log in as a user then become root" paradigm. I don't. I consider that unnecessarily burdensome.
I would argue that there's a significant number of people that work the same way I do. Trying to enforce a "be user, become root" policy through the installer isn't going to make any of us happy.
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
Thank you, Steve
On Wed, 2010-11-24 at 06:23 -0800, Steve Allen wrote:
Martin Gracik mgracik@redhat.com wrote:
I see, but what if you had a user "steve" with already setup sudo access for you, instead of the root account. Would that make your work more unpleasant?
In the sense that it is making extra work for me, yes. I would use the 'steve' account to set up the root account, then delete the 'steve' account.
Now you have to setup root account in the installer. So you have to setup at least one user account.
Root is a pre-existing account. All that is needed is to set a password for it.
To set up the password you need to fill in 2 text entries. Creating a new user is just 1 text entry more, your name, as the username would be suggested and filled in automatically. I don't see 1 text entry as a deal breaker.
The way I propose, you would still have to setup only one user, no more work on your side compared to the situation we have now. The user would just not be called root, but for example "steve".
Well, it would be more work for me -- see above. Admittedly, it's a one-time ten minute task to deal with, but multiply that by dozens of machines...
Or is there some reason that you absolutely need root access?
A significant number of people subscribe to the "log in as a user then become root" paradigm. I don't. I consider that unnecessarily burdensome.
I would argue that there's a significant number of people that work the same way I do. Trying to enforce a "be user, become root" policy through the installer isn't going to make any of us happy.
I agree that there are many people doing this, but logging in as root is I believe a security risk, and I think we should encourage the users to use policies that are more secure. And also, gdm does not allow you to login as root by default.
What I mean is that I don't think we should help anyone with using his system in an insecure way. You can definitely do it if you really want, but you should have to overcome some obstacles.
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
I know how you feel, there are many policies I don't agree with too, but they are used because many people believe, that it's better that way.
Thank you, Steve
Martin Gracik mgracik@redhat.com wrote:
To set up the password you need to fill in 2 text entries. Creating a new user is just 1 text entry more, your name, as the username would be suggested and filled in automatically. I don't see 1 text entry as a deal breaker.
But then I have an unnecessary account that I have to go back later and delete.
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
I know how you feel, there are many policies I don't agree with too, but they are used because many people believe, that it's better that way.
Shouldn't it be the organization using the software that sets policy, rather than the software vendor?
Steve
On Wed, 2010-11-24 at 07:07 -0800, Steve Allen wrote:
Martin Gracik mgracik@redhat.com wrote:
To set up the password you need to fill in 2 text entries. Creating a new user is just 1 text entry more, your name, as the username would be suggested and filled in automatically. I don't see 1 text entry as a deal breaker.
But then I have an unnecessary account that I have to go back later and delete.
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
I know how you feel, there are many policies I don't agree with too, but they are used because many people believe, that it's better that way.
Shouldn't it be the organization using the software that sets policy, rather than the software vendor?
I don't think it works like this all the time. For example, you have SELinux enabled by default in Fedora. You also have firewall enabled by default. Enabling those tools by default is a policy Fedora is enforcing, and you as a user (or organization) can disable it manually. This is similar to the root account situation.
Steve
On Wed, Nov 24, 2010 at 15:40:07 +0100, Martin Gracik mgracik@redhat.com wrote:
I agree that there are many people doing this, but logging in as root is I believe a security risk, and I think we should encourage the users to use policies that are more secure. And also, gdm does not allow you to login as root by default.
su'ing to root from a normal account has simlar risks. Exploits need to be a bit more complicated, but once they are script kiddie ready you don't gain much by having to give two passwords to get full access.
On Sun, Nov 28, 2010 at 06:04:20AM -0600, Bruno Wolff III wrote:
On Wed, Nov 24, 2010 at 15:40:07 +0100, Martin Gracik mgracik@redhat.com wrote:
I agree that there are many people doing this, but logging in as root is I believe a security risk, and I think we should encourage the users to use policies that are more secure. And also, gdm does not allow you to login as root by default.
su'ing to root from a normal account has simlar risks. Exploits need to be a bit more complicated, but once they are script kiddie ready you don't gain much by having to give two passwords to get full access.
It is more risky to run more code as root than to run less. Logging into a graphical desktop as root means /everything/ runs as root, from the window manager to the browser and everything in between. This is much more risky than just running a command or shell as root using sudo or su.
On Sun, Nov 28, 2010 at 10:26:59 -0500, Chuck Anderson cra@wpi.edu wrote:
It is more risky to run more code as root than to run less. Logging into a graphical desktop as root means /everything/ runs as root, from the window manager to the browser and everything in between. This is much more risky than just running a command or shell as root using sudo or su.
Not as much better as you might think. If the user account gets compromised (as opposed to cases where you make a mistake with a command), then later when it swiitches to root the malware can use the root credentials to do other bad stuff. This may give you time to notice the problem and requires the malware to be more complicated. The more complicated malware only needs to be written and distrbiuted once.
On Sun, 2010-11-28 at 13:00 -0600, Bruno Wolff III wrote:
On Sun, Nov 28, 2010 at 10:26:59 -0500, Chuck Anderson cra@wpi.edu wrote:
It is more risky to run more code as root than to run less. Logging into a graphical desktop as root means /everything/ runs as root, from the window manager to the browser and everything in between. This is much more risky than just running a command or shell as root using sudo or su.
Not as much better as you might think. If the user account gets compromised (as opposed to cases where you make a mistake with a command), then later when it swiitches to root the malware can use the root credentials to do other bad stuff. This may give you time to notice the problem and requires the malware to be more complicated. The more complicated malware only needs to be written and distrbiuted once.
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
I think it's not only about compromised accounts. The thing is that if you log in as root, you run everything as root, even stuff that does not need root privileges, and some of this software can do some bad things. If you log in as a normal user, and run everything as normal user, except for stuff that _really_ needs root privileges, there's a smaller chance some malware will have root privileges too, if you don't run it with sudo yourself. Of course there is always a chance that your system is attacked even with a normal user, but when you're using root as little as possible, you are lowering the chances of that.
Martin Gracik mgracik@redhat.com wrote:
is attacked even with a normal user, but when you're using root as little as possible, you are lowering the chances of that.
Let me just throw one more request out here... Please allow the setting of the root password as part of the installation process. It can be in an options pane or something, like a button on the create user screen.
I do installs in classified areas, and the way the installation and configuration procedures are written, they require a root login to set things up before user accounts are introduced to the machines. Without the initial root login, I'm stuck between a rock and a hard place.
Thanks, Steve
On Mon, Nov 29, 2010 at 8:09 AM, Steve Allen < allen@doobie.itdl.ds.boeing.com> wrote:
Martin Gracik mgracik@redhat.com wrote:
is attacked even with a normal user, but when you're using root as little as possible, you are lowering the chances of that.
Let me just throw one more request out here... Please allow the setting of the root password as part of the installation process. It can be in an options pane or something, like a button on the create user screen.
Huh?
Setting the root password is already part of the installation process. It comes right before selecting the time zone screen.
Gregory Woodbury redwolfe@gmail.com wrote:
On Mon, Nov 29, 2010 at 8:09 AM, Steve Allen < allen@doobie.itdl.ds.boeing.com> wrote:
Martin Gracik mgracik@redhat.com wrote:
is attacked even with a normal user, but when you're using root as little as possible, you are lowering the chances of that.
Let me just throw one more request out here... Please allow the setting of the root password as part of the installation process. It can be in an options pane or something, like a button on the create user screen.
Huh?
Setting the root password is already part of the installation process. It comes right before selecting the time zone screen.
The discussion in the last week or so has been on removing that option.
Steve
Another reason to use sudo for all access to root is for its logging ability. This isn't needed so much on desktops, but on servers with multiple people accessing root you know who ran what and when (assuming they didn't just run sudo su -).
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
Part of having this discussion on the mailing list is to see what other people's opinions on this are. We're always open to different viewpoints and haven't really decided anything one way or the other on this. I'm not willing to make a decision on it until we see some more mockups, personally.
- Chris
On Mon, 2010-11-29 at 22:08 +0000, Chris Lumens wrote:
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
Part of having this discussion on the mailing list is to see what other people's opinions on this are. We're always open to different viewpoints and haven't really decided anything one way or the other on this. I'm not willing to make a decision on it until we see some more mockups, personally.
Sorry it's been a week or so; I've been looking at the storage re-initialization popup [1].
Anyway, here's a couple of different mockups (sorry if the blue is too much, if the aesthetics are too scary just ignore them for the meat):
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Sudo_By_Default
I did two versions;
- version #1 is where you can simply use 'root' as your username and it'll set a root password instead of create a first user. One potentially weird/awkward thing here is that I don't think it's so nice to set a real person's name on a root account (is it even possible?) So I think the right thing to do in the case of setting the username = root is to blank out the 'Full Name' field and grey it out as well when 'root' is typed in the field.
- version #2 is where you can 'opt-in' to setting a root password with a bit of an explanation as to why you don't want to do it (to discourage folks who might not be up for it from doing it.) The explanation on that screen may be BS though, I made it up. :)
In both versions, you get extra screens by 'opting-in' to them via checkboxes (similar to how the partitioning screen works today.)
What do you think?
~m
[1] https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Storage_Reinit
On Tue, Dec 07, 2010 at 12:58:47PM -0500, Máirín Duffy wrote:
What do you think?
I like #1 better. Less things to check, easy to tab over to username and enter root and no need to add another screen that really just duplicates the user entry screen.
- version #1 is where you can simply use 'root' as your username and
it'll set a root password instead of create a first user. One potentially weird/awkward thing here is that I don't think it's so nice to set a real person's name on a root account (is it even possible?) So I think the right thing to do in the case of setting the username = root is to blank out the 'Full Name' field and grey it out as well when 'root' is typed in the field.
Setting the name is just adding information into the line in the /etc/passwd file, so I don't see why you couldn't also do it for root. I just don't think it's too commonly done.
In both versions, you get extra screens by 'opting-in' to them via checkboxes (similar to how the partitioning screen works today.)
On both, we're setting up the non-root user for sudo access, yeah? We should probably mention that we're doing that, though you wouldn't want to use the word "sudo". Say something about how this user will be authorized to perform system tasks, blah blah blah.
I need to spend some time thinking about these screens in the context of kickstart installs to make sure that whatever we allow today is still allowed after we make this change.
- Chris
On Tue, Dec 7, 2010 at 14:48, Chris Lumens clumens@redhat.com wrote:
- version #1 is where you can simply use 'root' as your username and
it'll set a root password instead of create a first user. One potentially weird/awkward thing here is that I don't think it's so nice to set a real person's name on a root account (is it even possible?) So I think the right thing to do in the case of setting the username = root is to blank out the 'Full Name' field and grey it out as well when 'root' is typed in the field.
Setting the name is just adding information into the line in the /etc/passwd file, so I don't see why you couldn't also do it for root. I just don't think it's too commonly done.
In both versions, you get extra screens by 'opting-in' to them via checkboxes (similar to how the partitioning screen works today.)
On both, we're setting up the non-root user for sudo access, yeah? We should probably mention that we're doing that, though you wouldn't want to use the word "sudo". Say something about how this user will be authorized to perform system tasks, blah blah blah.
I need to spend some time thinking about these screens in the context of kickstart installs to make sure that whatever we allow today is still allowed after we make this change.
What I have been doing for my systems lately and would love as a firstboot or similar is that I add the first user to desktop_admin_r and then make sudo use that group as root access with password. This allows for both "I need a password to do things" to key off the same group. At one place we worked we just had some sort of wording like:
If you will need administrative access for this system click here: [] and that did the sudo thing for that user.
- Chris
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, 2010-12-07 at 15:21 -0700, Stephen John Smoogen wrote:
On Tue, Dec 7, 2010 at 14:48, Chris Lumens clumens@redhat.com wrote:
- version #1 is where you can simply use 'root' as your username and
it'll set a root password instead of create a first user. One potentially weird/awkward thing here is that I don't think it's so nice to set a real person's name on a root account (is it even possible?) So I think the right thing to do in the case of setting the username = root is to blank out the 'Full Name' field and grey it out as well when 'root' is typed in the field.
Setting the name is just adding information into the line in the /etc/passwd file, so I don't see why you couldn't also do it for root. I just don't think it's too commonly done.
In both versions, you get extra screens by 'opting-in' to them via checkboxes (similar to how the partitioning screen works today.)
On both, we're setting up the non-root user for sudo access, yeah? We should probably mention that we're doing that, though you wouldn't want to use the word "sudo". Say something about how this user will be authorized to perform system tasks, blah blah blah.
I need to spend some time thinking about these screens in the context of kickstart installs to make sure that whatever we allow today is still allowed after we make this change.
What I have been doing for my systems lately and would love as a firstboot or similar is that I add the first user to desktop_admin_r and then make sudo use that group as root access with password. This allows for both "I need a password to do things" to key off the same group. At one place we worked we just had some sort of wording like:
If you will need administrative access for this system click here: [] and that did the sudo thing for that user.
This should already be possible https://bugzilla.redhat.com/show_bug.cgi?id=462161
- Chris
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, 2010-12-07 at 12:58 -0500, Máirín Duffy wrote:
On Mon, 2010-11-29 at 22:08 +0000, Chris Lumens wrote:
In the end, that's what I object to. It feels like an attempt to enforce a policy that I don't agree with. Let it be default to set up a local user account. But also let it be an option to bypass that and (or in addition) set the root password.
Part of having this discussion on the mailing list is to see what other people's opinions on this are. We're always open to different viewpoints and haven't really decided anything one way or the other on this. I'm not willing to make a decision on it until we see some more mockups, personally.
Sorry it's been a week or so; I've been looking at the storage re-initialization popup [1].
Anyway, here's a couple of different mockups (sorry if the blue is too much, if the aesthetics are too scary just ignore them for the meat):
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Sudo_By_Default
I did two versions;
- version #1 is where you can simply use 'root' as your username and
it'll set a root password instead of create a first user. One potentially weird/awkward thing here is that I don't think it's so nice to set a real person's name on a root account (is it even possible?) So I think the right thing to do in the case of setting the username = root is to blank out the 'Full Name' field and grey it out as well when 'root' is typed in the field.
- version #2 is where you can 'opt-in' to setting a root password with a
bit of an explanation as to why you don't want to do it (to discourage folks who might not be up for it from doing it.) The explanation on that screen may be BS though, I made it up. :)
In both versions, you get extra screens by 'opting-in' to them via checkboxes (similar to how the partitioning screen works today.)
What do you think?
~m
[1] https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Anaconda_Storage_Reinit
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
I like the first one, where you change the username to root more, but...
I tried doing that icon in the text entry in firstboot, but people didn't like it, because if you don't have an icon in one of them (like you don't in the username one), then the text is not aligned. Also what does that Full Name icon check for?
I also learned that the warning icons are intrusive, and not everybody knows he can hover his mouse over it, and see a tooltip, so they have no idea why there's a warning.
This is what I did to firstboot then http://mgracik.fedorapeople.org/create_user.png
There are no warning icons, just an apply icon, if everything is OK. And I also think, we could change that password strength label to a progress bar with text indicating the strength level.
Martin Gracik mgracik@redhat.com wrote:
What if the NIS server dies, how will you login in an emergency?
??? I log in as root.
Steve
I like the idea of not having root, and having only a local user setup with sudo rights in anaconda. Then if I really need the root account, I can do it in command line manually. In my opinion anaconda+firstboot should make life easier for people who don't know much about the system. If you're an advanced user, and really need a root user account, you should already have the knowledge how to create it in command line by yourself. You shouldn't need a GUI wizard for that.
True, but I also think we need to strike a balance to make sure things aren't too much of a pain on the advanced user. I mean, I like to think of myself as an advanced user as well and I'd prefer things to not be more difficult for me than they have to.
It seems like we can strike some balance here. Perhaps we start by merging the root password and create user screens together and offering some sort of choice. You can choose to set up a root password, or you can choose to create a regular user account and put that user into sudo. Default to the second choice. I'm not sure if we can make that make sense in the UI though.
- Chris
Chris Lumens clumens@redhat.com wrote:
It seems like we can strike some balance here. Perhaps we start by merging the root password and create user screens together and offering some sort of choice. You can choose to set up a root password, or you can choose to create a regular user account and put that user into sudo. Default to the second choice. I'm not sure if we can make that make sense in the UI though.
I'd be happy with that.
Steve
On Tue, Nov 23, 2010 at 02:37:10PM -0500, Chris Lumens wrote:
I like the idea of not having root, and having only a local user setup with sudo rights in anaconda. Then if I really need the root account, I can do it in command line manually. In my opinion anaconda+firstboot should make life easier for people who don't know much about the system. If you're an advanced user, and really need a root user account, you should already have the knowledge how to create it in command line by yourself. You shouldn't need a GUI wizard for that.
True, but I also think we need to strike a balance to make sure things aren't too much of a pain on the advanced user. I mean, I like to think of myself as an advanced user as well and I'd prefer things to not be more difficult for me than they have to.
It seems like we can strike some balance here. Perhaps we start by merging the root password and create user screens together and offering some sort of choice. You can choose to set up a root password, or you can choose to create a regular user account and put that user into sudo. Default to the second choice. I'm not sure if we can make that make sense in the UI though.
I think that would add more clutter to the interface. Using a normal user and sudo for root access is the safe way to do things. If advanced users want to use root setting it up isn't much of a burden -- in cases where you are deploying alot of systems you can easily setup a kickstart to do it for you.
On Tue, Nov 23, 2010 at 14:37:10 -0500, Chris Lumens clumens@redhat.com wrote:
It seems like we can strike some balance here. Perhaps we start by merging the root password and create user screens together and offering some sort of choice. You can choose to set up a root password, or you can choose to create a regular user account and put that user into sudo. Default to the second choice. I'm not sure if we can make that make sense in the UI though.
What if you were allowed to choose 'root' when asked for the account name for the user and something reasonable happened?
It seems like we can strike some balance here. Perhaps we start by merging the root password and create user screens together and offering some sort of choice. You can choose to set up a root password, or you can choose to create a regular user account and put that user into sudo. Default to the second choice. I'm not sure if we can make that make sense in the UI though.
What if you were allowed to choose 'root' when asked for the account name for the user and something reasonable happened?
I am torn between that being a nice way of making things just work and a little too magic. Perhaps mizmo has an idea on if that makes sense from a UI perspective.
- Chris
anaconda-devel@lists.fedoraproject.org
-
Brian C. Lane -
Bruno Wolff III -
Chris Lumens -
Chuck Anderson -
Gregory Woodbury -
Martin Gracik -
Máirín Duffy -
Stephen John Smoogen -
Steve Allen