Should this be optional? Does this actually get used under Fedora?
Bill
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
Should this be optional? Does this actually get used under Fedora?
I'd be for disabling it by default.
/B
We need to have this installed on the machine by default because it allows a user to enroll a smart card. This is required to make use of the smart card login feature.
thanks, Jack
Brian Pepple wrote:
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
Should this be optional? Does this actually get used under Fedora?
I'd be for disabling it by default.
/B
On Thu, 2007-10-04 at 13:50 -0700, Jack Magne wrote:
We need to have this installed on the machine by default because it allows a user to enroll a smart card. This is required to make use of the smart card login feature.
1. smart cards are extremely uncommon. 2. if you have an infrastructure requiring this then your sysadmin/user can install the pkg with a single command
why would it need to be on the default install?
-sv
Jack Magne (jmagne@redhat.com) said:
We need to have this installed on the machine by default because it allows a user to enroll a smart card. This is required to make use of the smart card login feature.
That's a logical fallacy.
Number of bugs filed against esc by non-RH people relating to its use: 0
Number of bugs filed against thinkfinger by non-RH people relating to its use: 2
And yet, we don't install thinkfinger by default. (We could then compare the number of users with fingerprint scanning hardware vs. smart cards.)
Bill
On Thu, 04 Oct 2007 13:50:15 -0700 Jack Magne jmagne@redhat.com wrote:
We need to have this installed on the machine by default because it allows a user to enroll a smart card. This is required to make use of the smart card login feature.
That's an argument for having it on the install media, but not an argument to install it by default.
On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
That's an argument for having it on the install media, but not an argument to install it by default.
Bogus. Extend this argument to other device drivers etc. and you pretty soon have a system that won't install / work anywhere.
David
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
That's an argument for having it on the install media, but not an argument to install it by default.
Bogus. Extend this argument to other device drivers etc. and you pretty soon have a system that won't install / work anywhere.
extend it in the other direction and pretty soon you have a system that won't be able to fit on any media, anywhere.
I think the point we're making here is that we need to find a happy balance. I think smart cards are obscure enough to not include them by default. -sv
On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote:
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
That's an argument for having it on the install media, but not an argument to install it by default.
Bogus. Extend this argument to other device drivers etc. and you pretty soon have a system that won't install / work anywhere.
extend it in the other direction and pretty soon you have a system that won't be able to fit on any media, anywhere.
I think the point we're making here is that we need to find a happy balance. I think smart cards are obscure enough to not include them by default.
Maybe. But it shouldn't have to be that way; smart cards (or anything where you verify more than one thing about the user (e.g. the classic something you a) have; b) know; c) are) are inherently more secure than just passwords and SSH keys. Hence, I think we should be interested in getting this working. Same for thinkfinger; people are doing very good work at integrating this into the distro.
(Heck, if I'm a big company interested in this I should be able to participate in the Fedora project and get my stuff into the distro so it Just Works(tm) out of the box. Maybe even offer some or all Fedora developers a smart card. Just a thought.)
But you're right; it's about balance; there's a couple of kernel drivers we don't ship because they're just too obscure. Or they're too buggy. Or too bloated. Whatever. Ideally our OS should be able to detect the hardware and properly request for the driver / enabling software to be installed (clearly, this won't work for kernel drivers now that kmod's are banned but there's a lot of other stuff in userspace).
(I do think, however, that pscs-lite and esc should be installed by default as soon they've fixed their resource consumption issues; at least until our OS is smart enough to detect what RPM's to install when we see the hardware [1])
David
[1] : e.g. modalias; the package will have a Provides: usb:v413Cp8103d2422dcE0dsc01dp01icFEisc01ip00
David Zeuthen wrote:
On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote:
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: I think the point we're making here is that we need to find a happy balance. I think smart cards are obscure enough to not include them by default.
Maybe. But it shouldn't have to be that way; smart cards (or anything where you verify more than one thing about the user (e.g. the classic something you a) have; b) know; c) are) are inherently more secure than just passwords and SSH keys. Hence, I think we should be interested in getting this working. Same for thinkfinger; people are doing very good work at integrating this into the distro.
Everything Red Hat is doing is driving towards the use of stronger authentication. We have made huge monetary investments in this area. Fedora is supposed to be a test ground for emerging technology, especially emerging technology be driven by us. These observations should help answer the question of whether these packages should be candidates for default installation because that will help move the technology forward we have a vested interest in.
John Dennis wrote:
David Zeuthen wrote:
On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote:
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote: I think the point we're making here is that we need to find a happy balance. I think smart cards are obscure enough to not include them by default.
Maybe. But it shouldn't have to be that way; smart cards (or anything where you verify more than one thing about the user (e.g. the classic something you a) have; b) know; c) are) are inherently more secure than just passwords and SSH keys. Hence, I think we should be interested in getting this working. Same for thinkfinger; people are doing very good work at integrating this into the distro.
Everything Red Hat is doing is driving towards the use of stronger authentication. We have made huge monetary investments in this area.
It be would useful if some of the investments were directed to not making ti start by default unnecessary. The majority of end users in Fedora are unlikely to be using smart cards anytime soon unlike the audience for RHEL.
Rahul
On 10/5/07, David Zeuthen davidz@redhat.com wrote:
But you're right; it's about balance; there's a couple of kernel drivers we don't ship because they're just too obscure. Or they're too buggy. Or too bloated. Whatever. Ideally our OS should be able to detect the hardware and properly request for the driver / enabling software to be installed (clearly, this won't work for kernel drivers now that kmod's are banned but there's a lot of other stuff in userspace).
Detection of this at install time? Even if all the pieces to do that are available, doesn't that require some significant re-think in installer package management? At the very least we'd have to have a list of packages associated which each sort of hardware detection flag that could be parsed by the installer. Using what we have currently as a starting point, you'd essentially have to group things in a comps group associated with each detection criteria, and then teach anaconda to set that group to install by default if the detection criteria is met.
And when installing from livecd targets... could you discriminate in a similar fashion and only install to disk the hardware specific userspace bits that system needed? I think that'd be tougher since the livecd's install a pre-cooked disk image with all the bells and whistles already installed.
-jef
On Fri, 2007-10-05 at 10:48 -0800, Jeff Spaleta wrote:
On 10/5/07, David Zeuthen davidz@redhat.com wrote:
But you're right; it's about balance; there's a couple of kernel drivers we don't ship because they're just too obscure. Or they're too buggy. Or too bloated. Whatever. Ideally our OS should be able to detect the hardware and properly request for the driver / enabling software to be installed (clearly, this won't work for kernel drivers now that kmod's are banned but there's a lot of other stuff in userspace).
Detection of this at install time?
No, it's basically the wrong mindset to think that we only need to detect hardware at install time; with hot pluggable buses like USB, Firewire, whatever, hardware can come and go at any time. So any solution that only works at install time is just fundamentally wrong.
In fact, the installer just be just an installer; not it's own little OS with it's own private hardware detection routines; that kind of services should be part of the core OS and the installer should take advantage of it as should the environment the user normally use too (e.g. the desktop or commandline tools)
Even if all the pieces to do that are available, doesn't that require some significant re-think in installer package management? At the very least we'd have to have a list of packages associated which each sort of hardware detection flag that could be parsed by the installer. Using what we have currently as a starting point, you'd essentially have to group things in a comps group associated with each detection criteria, and then teach anaconda to set that group to install by default if the detection criteria is met.
Yes, it's a can of worms; basically what most "Enterprise" distros do (because they have a kABI and support vendor drivers not shipped with the OS etc.) is to use RPM Provides: with the modalias for what the driver in the RPM support. So it goes like this
1. Plug in your hardware 2. Find the modalias for the device (look e.g. in sysfs) 3. yum search $modalias 4. yum install package-that-you-found
It's not really difficult to imagine this could be automated; you'd have a small tray icon saying "yo, I don't have a driver for this device; would you like to search for one?".
Of course the party line of Fedora is (or used to be) that we install all drivers in the default install and that renders the problem moot. In fact, I think it's a bit silly to build all this infrastructure just because
- we've changed the party line from "we ship all drivers in the default install" to "we don't ship all drivers in the default install". This kind of baffles me; I'm not really sure DVD space and hard disk space is that expensive.
- it creates the illusion that Fedora has a stable kABI; that's just wrong
- it'll never work for kernel drivers anyway and the majority of interesting drivers are indeed in the kernel
- it's just plain annoying having to click through crap like that just because we decided not to ship all drivers in the default install. Of course, such a gizmo has the side effect to tell you if the hardware you just plugged in is supported or not so we may end up doing something similar *anyway*.
And when installing from livecd targets... could you discriminate in a similar fashion and only install to disk the hardware specific userspace bits that system needed? I think that'd be tougher since the livecd's install a pre-cooked disk image with all the bells and whistles already installed.
I can't really see what's wrong with "we ship all drivers in the default install" but if we want to change it we need some of that silly infrastructure above to make the system Just Work(tm) when you e.g. plug in a USB smart card reader.
David
David Zeuthen (davidz@redhat.com) said:
I do think, however, that pscs-lite and esc should be installed by default as soon they've fixed their resource consumption issues;
I have no problems with that. But running a separate daemon and xulrunner stack on login for hardware that a fairly minute fraction of our users will ever have isn't really up to snuff right now.
Bill
Thanks everyone for the thoughtful responses and suggestions. We will continue to work to solve these issues.
thanks, jack
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
That's an argument for having it on the install media, but not an argument to install it by default.
Bogus. Extend this argument to other device drivers etc. and you pretty soon have a system that won't install / work anywhere.
I have a hard time imagining a system that won't install because of missing smart card drivers.
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
Should this be optional? Does this actually get used under Fedora?
As a general rule of thumb we do try hard to ship as many drivers / hardware enablement features as possible. I'm not sure why esc is any different?
Maybe.. because of the fact that it's a resource hog (both in terms of eating cycles and taking up disk space). At least it was like this the last time I looked [1].
(Btw, for me, the resource hog issue alone should be enough to kick it out of the default install. Think boot time, live image size etc. And if this is the case, we should just say it like it is. It might also help get someone to fix it.)
David
[1] : for starters, they ship their own mozilla stack
You are correct about the physical size.
The upcoming system wide Xulrunner should help us there.
By default , only a smaller smart card detection daemon run until someone puts in an actual card.
thanks, jack
David Zeuthen wrote:
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
Should this be optional? Does this actually get used under Fedora?
As a general rule of thumb we do try hard to ship as many drivers / hardware enablement features as possible. I'm not sure why esc is any different?
Maybe.. because of the fact that it's a resource hog (both in terms of eating cycles and taking up disk space). At least it was like this the last time I looked [1].
(Btw, for me, the resource hog issue alone should be enough to kick it out of the default install. Think boot time, live image size etc. And if this is the case, we should just say it like it is. It might also help get someone to fix it.)
David
[1] : for starters, they ship their own mozilla stack
On Thu, 2007-10-04 at 14:51 -0700, Jack Magne wrote:
By default , only a smaller smart card detection daemon run until someone puts in an actual card.
Even this is wrong. You should use either udev or hal to ensure that the daemon is running only when the hardware is present (assuming USB; if people still use serial ports then they can manually edit some config file to make sure the daemon starts up.)
David
Yes, we have a bug on the issue to to tie smart card detection to hal.
thanks, jack
David Zeuthen wrote:
On Thu, 2007-10-04 at 14:51 -0700, Jack Magne wrote:
By default , only a smaller smart card detection daemon run until someone puts in an actual card.
Even this is wrong. You should use either udev or hal to ensure that the daemon is running only when the hardware is present (assuming USB; if people still use serial ports then they can manually edit some config file to make sure the daemon starts up.)
David
desktop@lists.fedoraproject.org