June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Marcus Meissner (msmeissn) Feature #302628, revision 35 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) #15: Mario Goppold (mgoppold) (2009-03-29 22:26:03) Hi, because I just need to unlook my root partition via USB stick I have build an rpm for it: http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_… _SVNr46_luks_key-64.1.x86_64.rpm The main changes are in /lib/mkinitrd/scripts/{setup,boot}-luks.sh and the new /etc/sysconfig/initrd.luks_key. The LUKS-Keyfile should on an Labled or UUIDed USB-Stick. You can unlook all partitions with a master key or define a separate for every luks_device. The approach is certainly not the best but there is no keyscript in /etc/crypttab jet (why not?). #16: Ludwig Nussel (lnussel) (2009-03-30 09:13:46) (reply to #15) mind creating a patch against http://git.opensuse.org/?p=projects/boot.crypto.git;a=summary so I can have a look? I'm not really fond of supporting the keyscript option but since debian now uses that askpass program that I like to integrate we'd basically get keyscript support for free at least wrt boot.crypto. For YaST it would be between hard and impossible to support as one can never know what the keyscript does. #17: Mario Goppold (mgoppold) (2009-03-30 22:14:47) (reply to #16) - Have a look at boot.crypto-035e11e5c04eb03ca972baf135a12b869e758f91. - luks-key.dif (https://build.opensuse.org/package/view_file?file=boot.crypto-035e11e5c04eb… - 3Amgoppold) an the new rpm Build 73 (https://api.opensuse.org/build/home:mgoppold/openSUSE_11.1/x86_64/cryptsetu… - _SVNr46_luks_key-73.1.x86_64.rpm) + Have a look at #18: Mario Goppold (mgoppold) (2009-04-01 20:59:06) (reply to #16) I have made some little updates: * There is no need to add /dev/mapper/swap and /dev/mapper/what_else to setup-storage.sh. or /boot/grub/menu.lst * If the key-File is not within the luks-Container there is now a prompt fallback. * I added ext3 and jbd modules to have the Key on ext3 formatted USB- Sticks The new version is Build 77 (http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_…) + #19: Marcus Meissner (msmeissn) (2009-06-24 15:12:33) (reply to #18) + Mario, It would really help us if you could provide a patch against the + current git state. + The patch does not aspply to current :( + (Ludwig is not in the office this and next week, will get back in 2 + weeks.) -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 306102] add computer name in the automatic configuration install
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Alin M Elena (ealin) Feature #306102, revision 1, last change by Title: add computer name in the automatic configuration install openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Alin M Elena (ealin) Description: It may be very useful if the user can change the name of the computer even if is in Automatic configuration during the installation. Reason why? All other major OS let you do that. ubuntu and fedora do it too. Alin PS This issue was discussed here too https://bugzilla.novell.com/show_bug.cgi?id=478602 Unfortunately the person who closed it was not open to discussions. -- openSUSE Feature: https://features.opensuse.org/306102

1 5

[openFATE 306326] mount encrypted /home before user config
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #306326, revision 4 Title: mount encrypted /home before user config openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Stefan Behlert (sbehlert) Description: Taken from bugzilla, requested by development. When installing with an encrypted /home partition I am informed during user creation that the /home partition is not mounted (see screenshot in bugzilla). What is missing here is the possibility to enter the password for the partition, mount the partiton and continue with the user configuration. Relations: - mount encrypted /home before user config (novell/bugzilla/id: 456004) https://bugzilla.novell.com/show_bug.cgi?id=456004 + Discussion: + #1: Stephan Kulow (coolo) (2009-06-24 12:37:08) + according to the bugzilla, it's a cryptsetup feature. -- openSUSE Feature: https://features.opensuse.org/306326

1 0

[openFATE 306028] A log structured filesystem like nilfs as root file-system for SSD based devices
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #306028, revision 7 Title: A log structured filesystem like nilfs as root file-system for SSD based devices - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-06-24 12:31:45 + reject reason: Out of scope for 11.2 Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Nikanth K (nikanth) Description: A log structured file-system like nilfs as root file-system to use on SSDs. Currently GRUB does not have support for those file-systems. So may be an option to have LILO for those configurations or add support for those in GRUB. Discussion: #4: Nikanth K (nikanth) (2009-05-07 14:36:45) Another option would be to have a /boot partition(or disk) and allow the root partition(or disk) as nilfs(or btrfs). I guess this should require only YaST changes. No LILO support required. -- openSUSE Feature: https://features.opensuse.org/306028

1 0

[openFATE 305574] Integrate ftrace
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305574, revision 5 Title: Integrate ftrace - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Jan Blunck (janblunck) Description: The ftrace infrastructure currently available in upstream kernels comes with different tracers. Having these tracers general available would enable us to find performance and functional regressions more easily during development and in support. Some of them need further work to be included in production kernels (so they don't depend on frame pointers etc.). Discussion: #1: Greg Kroah-Hartman (gregkh) (2009-01-20 05:11:51) We will get these automatically with the 11.2 release, so I don't see this as a big issue at all. Is there something different that we need to do to support these tracers? + #2: Stephan Kulow (coolo) (2009-06-24 12:21:35) (reply to #1) + ok, so I set this to done -- openSUSE Feature: https://features.opensuse.org/305574

1 0

[openFate 305721] Desktop should survive a dbus restart
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Vincent Untz (vuntz) Feature #305721, revision 1, last change by Title: Desktop should survive a dbus restart openSUSE-11.2: New Priority Requester: Important Requested by: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: Many applications have issues when dbus is restarted. It seems people want this to be possible, see for example https://bugzilla.novell.com/show_bug.cgi?id=439616 This is more than just a bug, and covers many packages, so I'm opening this feature to track this. On the GNOME side, the mandatory part are probably gdm and gnome-session, in order to not have the current sessions closed. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305721

1 2

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305657, revision 9 Title: finer grained PolicyKit support for Networkmanager openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup -- openSUSE Feature: https://features.opensuse.org/305657

1 0

[openFate 305683] Add web browser for SUSE Installation
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature added by: Vincent Steenhoute (civ75) Feature #305683, revision 1, last change by Title: Add web browser for SUSE Installation openSUSE-11.2: New Priority Requester: Desirable Requested by: Vincent Steenhoute (civ75) Interested: Vincent Untz (vuntz) Partner organization: openSUSE.org Description: While installing SUSE with the classic installation CD/DVD, add a web browser. Somes peoples don't use LiveCD and prefer Install DVD, giving them possibility to browse internet while all the package are installed would be a must. I guess Webkit will fit nicely with the QT UI of our installation. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305683

1 14

[openFATE 305489] default email in email applications
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305489, revision 16 Title: default email in email applications openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable - Requested by: Martin Lasarsch (mlasars) + Requested by: Michael Löffler (michl19) Description: To get more subscriptions to the mailinglists it would be nice to have a "default mail" in the mail clients (evolution, kmail) which points the user to the mailinglists. Every openSUSE user should be subscribed to opensuse-announce at least. A simple reply to this "default mail" should subscribe to the list (so it's opt-in, no one should be forced). Of course there could be more information in it, like other important lists, pointing to the main list page. evolution have already a "default mail", with general information about evolution, kmail afaik not. This might be also useful for OEM customers to have a welcome mail for the customers, pointing to the support pages etc.. So general email "branding" packages which makes it possible to have such special "default mails" for the email clients would be usefull. Discussion: #1: Carlos Lange (cflange) (2009-01-17 19:59:30) There are several parts to this suggestion. 1) "default mail": If you mean "Default" in the sense that when I start a new message the To: field is filled out by default with the mailing- list address, I disagree with your comment. The user should set that and an inexperienced user should find herself/himself subscribing to a mailing-list by mistake, just because they forgot to reset the To: field. Such a user would be rightly upset and feel like they were trapped into doing it. 2) If you mean, however, that the address book in Evolution and Kmail should be pre-populated with relevant addresses, such as the mailing- list and others, in the same way the Firefox bookmarks toolbar comes pre-populated with the SUSE folder, then I would agree that this is a useful suggestion, because the user can freely choose to use those addresses or not. 3) I strongly disagree that every openSUSE user should be subscribed to the opensuse-announce mailing-list. I deal with many different types of users. Only a minority of them would be interested in receiving announcements and they actively subscribe to the mailing-list. The vast majority of them likes the Linux-way of being non-intrusive, without the nags and unsolicited messages from the proprietary world, that tend to be associated with annoying marketing strategies. Please, don't advocate that for openSUSE. The SUSE information box shown at the first login is as much in-your- face direct marketing as one should need to take when using openSUSE. And being beautiful and carefully designed as it is, it contains all information a new user needs to decide how much involved with the operating system they want to be. #2: Joe Brockmeier (jbrockmeier) (2009-01-20 02:05:37) (reply to #1) Perhaps "every" is a bit much, but I feel a lot more people should be subscribed than are currently. I find it's not uncommon to talk to people and see that they're unaware of something happening in the community that has been announced on the mailing list. The percentage of people subscribed to -announce is much less than 1% of openSUSE users, and I feel we could be reaching a lot more people. It's not an "annoying marketing strategy," it's an attempt to keep our community informed. Most of the messages that go to announce are not "marketing" in nature, they're informative. #3: Kevin Dupuy (kdupuy9) (2009-01-20 02:49:32) (reply to #2) I also like the idea of having more users subscribed to the -announce list. Every time there is scheduled downtime, even though it is announced on -announce and openSUSE News, some people come on the opensuse(a)o.o mailinglist "eh, what happened? the servers are down, suse is unreliable!",. so those type of mails I'd like for more users to get. Then again perhaps not every user wants to know when the next project meeting is, so that's a strike against the idea as well. I do think, as with Carlos, that the address book in Kontact and Evolution should have some important email address in there (opensuse(a)o.o, anything else?) #4: Martin Lasarsch (mlasars) (2009-01-20 17:12:09) (reply to #1) 1. no 2. maybe, why not 3. should means as an opt-in ... not forcing With default i meant to have a simple email in the inbox to make it easier to subscribe to the announce list. #5: Stefan Behlert (sbehlert) (2009-03-26 10:58:17) I think the idea of having some addresses in the addressbook is good. I'm not sure which one's are the ideal ones for that, though. Let'S start with a few and add what is found missing later. #6: Stephan Kulow (coolo) (2009-06-24 11:32:12) (reply to #5) for opensuse this unfortunately not useful. as the subscription address is pretty useless in the address book as you only need once. And you can't post to opensuse(a)opensuse.org without being subscribed. So some more explanation is needed there - of course in the language of the user. #7: Stephan Kulow (coolo) (2009-06-24 11:34:39) I think there are some issues to be sorted out before we can go forward, perhaps someone from the marketing team wants to drive this -- openSUSE Feature: https://features.opensuse.org/305489

1 0

[openFATE 305560] Ability to Install 32bit and 64bit Debuginfo (and Sources) in Parallel
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #305560, revision 6 Title: Ability to Install 32bit and 64bit Debuginfo (and Sources) in Parallel openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Desirable Requested by: Jan Blunck (janblunck) Description: Allow the installation of libraries and debuginfo packages of multiple architectures and multiple versions of the same library. Currently the debugedit command run by the buildprocess to rewrite the paths inside the debuginfo to match the installed system is not able to handle the case when pathnames grow. The tools needs a complete redesign for that to work. This isn't a duplicate of FATE #302050, since it is focused on the toolchain that is processing the debuginfo packages instead of the package management tools. Relations: - rename -debuginfo rpms to -debuginfo-32bit / -debuginfo-64bit (novell/bugzilla/id: 143477) https://bugzilla.novell.com/show_bug.cgi?id=143477 + Discussion: + #1: Stephan Kulow (coolo) (2009-06-24 11:41:53) + Looking for community volunteers - are there any bug reports about it + not working, btw? -- openSUSE Feature: https://features.opensuse.org/305560

1 0