January 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature changed by: Marcus Meissner (msmeissn) Feature #302628, revision 52 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: Candidate 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 #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.) #20: Mario Goppold (mgoppold) (2009-08-11 09:38:09) (reply to #19) The new patch against the boot.crypto- 2acb4efc564ca9af8e97162110987289f1206f11.tar.gz from 13.07.2009 is done. You can find it in my OBS: #21: Mario Goppold (mgoppold) (2009-08-11 17:42:20) (reply to #20) Now, it builds on Factory too. #22: Matthias Nagorni (mnagorni) (2009-08-21 13:37:03) (reply to #21) Certainly a nice feature and as I understand it is close to ready. Since I like the innovation and do agree that crypto FS features and the corresponding indentity issues are highly important, I set to "Important". If I had a real business case I would even consider "Mandatory". #24: Stephan Kulow (coolo) (2009-09-03 10:49:40) (reply to #22) Marcus is on vacation this week, so I talked to Ludwig and the feature as it is makes it _possible_ to implement your own keyscript (see #16). This does not make it enterprise ready at all as it's not supported at all by the system beyond that. So please reject for SP1. Perhaps we get a matured version for SLE12. #23: Marcus Meissner (msmeissn) (2009-08-25 11:02:43) (reply to #21) Ludwig, can we proceed? #25: Ludwig Nussel (lnussel) (2009-09-04 12:37:22) I've submitted boot.crypto with support for a debian compatible keyscript option to Factory. passdev.c from debian or an equivalent still needs to be packaged. + #26: Marcus Meissner (msmeissn) (2010-01-15 16:21:20) (reply to #25) + can we mark it done? -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 308334] Distribute individual letters across cell width and height (aka 均等割符)
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 24 Title: Distribute individual letters across cell width and height (aka 均等割符) Requested by: Kohei Yoshida (kohei_yoshida) Description: Distribute letters at equal intervals across cell's width such that the first and last letters are aligned with the left and right edge of the cell, respectively. Also support similar distribution mechanism in a vertical direction. This functionality is also known as Kin-tou Wari-fu (均等割符) in Japanese, and is very common operation among Japanese Excel users. Relations: - i#107467 - Excel import issue with cells with distributed content (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107467) - i#107470 - Request for this feature in the upstream IZ (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107470) - i#53373 - Jusitification issue in Draw/Impress for Japanese text. (url: http://qa.openoffice.org/issues/show_bug.cgi?id=53373) - User-contributed doc on text justification in Japanese text. (url: http://wiki.services.openoffice.org/wiki/User:Foral/Spec/Justification) Use Case: Sentences in the Japanese language do not normally break at each word unlike most Western languages. The normal justification functionality is therefore useless for the Japanese users. Instead, they typically justify sentences by adjusting spaces between letters, which is what this requested functionality will provide. Discussion: #3: Kohei Yoshida (kohei_yoshida) (2010-01-05 14:22:02) I've started looking into this. #4: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:36:46) Here is the initial hurdle: Calc uses XSL-FO for all text formatting, and fo:text-align specifies the alignment of a text (I assume for both horizontal and vertical directions). The bad news is that, this attribute does not allow a "distributed" alignment, but in order for us to implement this feature, we need that to allow a distributed alignment. Reference: http://www.w3.org/TR/xsl/#text-align #5: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:45:10) (reply to #4) Well, I guess I could use the "justify" alignment and additional flag to specify how the content is justified. The spec allows user-agent- specific justification algorithm, so it's doable without breaking the standard. #6: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:49:15) (reply to #5) And we could perhaps use the 'text-justify' attribute to specify the justification algorithm. See below: http://www.w3.org/TR/1999/WD-i18n-format-19990910/#a5 #7: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:59:37) (reply to #6) This one is the latest spec of the fore-cited: http://www.w3.org/TR/i18n-format/#text-justify #8: Kohei Yoshida (kohei_yoshida) (2010-01-08 12:39:43) Ok. Here is how I've decided to store this in ODF. For both normal justifiation and distributed justification, the style attribute 'fo:text-align' is saved as 'justify'. Then, for the distributed justification, an additional style attribute 'csstext3:text- justify' gets stored with a value of 'distribute'. For the normal justification, either this value is 'auto', or this attribute won't get stored at all. It took me a while to get to this point since OOo's handling of style attributes and how they are exported to xml are very complex. But I eventually got it to save and load correctly. #9: Kohei Yoshida (kohei_yoshida) (2010-01-11 13:23:40) For alignment in vertical direction, the current ODF uses style: vertical-align attribute which can be either one of: automatic, bottom, middle, top. First, we need to add a new alignment type 'justify' to the style:vertical-align, and use another attribute to specify the justification method. This would be similar to how the horizontal justification is handled. The problem is that we can't reuse the same 'text-justify' attribute name since that would clash with the horizontal justification method attribute. We need a new attribute name for this to avoid such naming clash. The first name that comes to mind is style:vertical-justify , which specifies the same set of values that the csstext3:text-justify supports. Of course, this imlies that to finalize this feature we need to get blessing from the ODF TC, which may not happen in a timely manner. We need to come up with a "solution" for that as well. #10: Kohei Yoshida (kohei_yoshida) (2010-01-11 22:20:20) So, I was wrong in thinking that this would be a very simple task. Not at all... Calculating text / char spacing involves at least 3 modules: sc, svx, and vcl. So, while the text attributes themselves originate from sc, the actual drawing of the text is done by svx and vcl. On the bright side, once we implement this feature, it would be trivial to extend this support to Draw and Impress as well, since those two apps simply re-use the same text rendering code. #11: Kohei Yoshida (kohei_yoshida) (2010-01-12 15:38:08) (reply to #10) Finally found where the text justification code is. Luckily fixing this there will automatically fix it for all of Calc/Impress/Draw for the Japanese text processing. #12: Kohei Yoshida (kohei_yoshida) (2010-01-12 16:01:07) (reply to #11) Just fixed i#53373 (http://qa.openoffice.org/issues/show_bug.cgi?id=53373) by accident. + #13: Kohei Yoshida (kohei_yoshida) (2010-01-15 09:14:05) + Implementation is nearing to a finish. What remains to be done are: + 1) formally propose a file format change to ODF TC. At least file a + change proposal to JIRA (TC's bug database). + 2) work on the xls and xlsx import and export filters, to support the + new text alignments. + 3) support distributed justification in Impress and Draw. + in order or priority. -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[openFATE 308334] Distribute individual letters across cell width and height (aka 均等割符)
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 25 Title: Distribute individual letters across cell width and height (aka 均等割符) Requested by: Kohei Yoshida (kohei_yoshida) Description: Distribute letters at equal intervals across cell's width such that the first and last letters are aligned with the left and right edge of the cell, respectively. Also support similar distribution mechanism in a vertical direction. This functionality is also known as Kin-tou Wari-fu (均等割符) in Japanese, and is very common operation among Japanese Excel users. Relations: - i#107467 - Excel import issue with cells with distributed content (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107467) - i#107470 - Request for this feature in the upstream IZ (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107470) - i#53373 - Jusitification issue in Draw/Impress for Japanese text. (url: http://qa.openoffice.org/issues/show_bug.cgi?id=53373) - - User-contributed doc on text justification in Japanese text. (url: http://wiki.services.openoffice.org/wiki/User:Foral/Spec/Justification) + - User-contributed doc on text justification in Japanese text. (url: + http://wiki.services.openoffice.org/wiki/User:Foral/Spec/Justification) + - + i#71067 - RFE: Distributed justification in Draw. (url: + http://www.openoffice.org/issues/show_bug.cgi?id=71067) Use Case: Sentences in the Japanese language do not normally break at each word unlike most Western languages. The normal justification functionality is therefore useless for the Japanese users. Instead, they typically justify sentences by adjusting spaces between letters, which is what this requested functionality will provide. Discussion: #3: Kohei Yoshida (kohei_yoshida) (2010-01-05 14:22:02) I've started looking into this. #4: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:36:46) Here is the initial hurdle: Calc uses XSL-FO for all text formatting, and fo:text-align specifies the alignment of a text (I assume for both horizontal and vertical directions). The bad news is that, this attribute does not allow a "distributed" alignment, but in order for us to implement this feature, we need that to allow a distributed alignment. Reference: http://www.w3.org/TR/xsl/#text-align #5: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:45:10) (reply to #4) Well, I guess I could use the "justify" alignment and additional flag to specify how the content is justified. The spec allows user-agent- specific justification algorithm, so it's doable without breaking the standard. #6: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:49:15) (reply to #5) And we could perhaps use the 'text-justify' attribute to specify the justification algorithm. See below: http://www.w3.org/TR/1999/WD-i18n-format-19990910/#a5 #7: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:59:37) (reply to #6) This one is the latest spec of the fore-cited: http://www.w3.org/TR/i18n-format/#text-justify #8: Kohei Yoshida (kohei_yoshida) (2010-01-08 12:39:43) Ok. Here is how I've decided to store this in ODF. For both normal justifiation and distributed justification, the style attribute 'fo:text-align' is saved as 'justify'. Then, for the distributed justification, an additional style attribute 'csstext3:text- justify' gets stored with a value of 'distribute'. For the normal justification, either this value is 'auto', or this attribute won't get stored at all. It took me a while to get to this point since OOo's handling of style attributes and how they are exported to xml are very complex. But I eventually got it to save and load correctly. #9: Kohei Yoshida (kohei_yoshida) (2010-01-11 13:23:40) For alignment in vertical direction, the current ODF uses style: vertical-align attribute which can be either one of: automatic, bottom, middle, top. First, we need to add a new alignment type 'justify' to the style:vertical-align, and use another attribute to specify the justification method. This would be similar to how the horizontal justification is handled. The problem is that we can't reuse the same 'text-justify' attribute name since that would clash with the horizontal justification method attribute. We need a new attribute name for this to avoid such naming clash. The first name that comes to mind is style:vertical-justify , which specifies the same set of values that the csstext3:text-justify supports. Of course, this imlies that to finalize this feature we need to get blessing from the ODF TC, which may not happen in a timely manner. We need to come up with a "solution" for that as well. #10: Kohei Yoshida (kohei_yoshida) (2010-01-11 22:20:20) So, I was wrong in thinking that this would be a very simple task. Not at all... Calculating text / char spacing involves at least 3 modules: sc, svx, and vcl. So, while the text attributes themselves originate from sc, the actual drawing of the text is done by svx and vcl. On the bright side, once we implement this feature, it would be trivial to extend this support to Draw and Impress as well, since those two apps simply re-use the same text rendering code. #11: Kohei Yoshida (kohei_yoshida) (2010-01-12 15:38:08) (reply to #10) Finally found where the text justification code is. Luckily fixing this there will automatically fix it for all of Calc/Impress/Draw for the Japanese text processing. #12: Kohei Yoshida (kohei_yoshida) (2010-01-12 16:01:07) (reply to #11) Just fixed i#53373 (http://qa.openoffice.org/issues/show_bug.cgi?id=53373) by accident. #13: Kohei Yoshida (kohei_yoshida) (2010-01-15 09:14:05) Implementation is nearing to a finish. What remains to be done are: 1) formally propose a file format change to ODF TC. At least file a change proposal to JIRA (TC's bug database). 2) work on the xls and xlsx import and export filters, to support the new text alignments. 3) support distributed justification in Impress and Draw. in order or priority. -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[openFATE 304500] Make storage failures non-fatal
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature changed by: Arvin Schnell (aschnell) Feature #304500, revision 31 Title: Make storage failures non-fatal openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 13:04:58 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:34:12 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important - openSUSE-11.3: Evaluation + openSUSE-11.3: Done Priority Requester: Important Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently all storage failures (during step "Prepare Harddisk") are fatal. E.g. if a partition cannot be mounted the installation is aborted. Some failures do not really harm, e.g. if mounting of a Windows partition fails that is not used for the installation. For other failures an really experienced user might fix the problem manually on the console. So for all failures the user should be asked whether the installation should continue. References: https://bugzilla.novell.com/show_bug.cgi?id=382765#c1 https://bugzilla.novell.com/show_bug.cgi?id=397156 https://bugzilla.novell.com/show_bug.cgi?id=402812 https://bugzilla.novell.com/show_bug.cgi?id=438660 https://bugzilla.novell.com/show_bug.cgi?id=520902 Relations: - Installation aborts after error message that NTFS partition can't be mounted (novell/bugzilla/id: 309074) https://bugzilla.novell.com/show_bug.cgi?id=309074 Discussion: #2: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:33:20) Please reject for SLE11/11.1. All resources allocated with mandatory features already. #6: Greg Riedesel (gracal) (2009-07-15 21:49:09) When installng openSUSE on a latop with a hybernated Windows parition, the current behavior will hard-stop the install. In some instances, if there was a prior openSUSE install, the boot files may have already been scrubbed when the mount-failure occurs that hard-stops the install. In this case, the laptop will become unbootable. The only way around it is to complete the openSUSE install, and explicitly remove the Windows parititions from fstab as part of the disk-parititioning dialog. That way the Windows partitions are not mounted during installation and won't throw an error. + #7: Arvin Schnell (aschnell) (2010-01-15 14:01:02) + Implemented for openSUSE 11.3. -- openSUSE Feature: https://features.opensuse.org/304500

1 0

[openFATE 306589] Improve help for CA Management
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature added by: Michael Calmer (mcalmer) Feature #306589, revision 1 Title: Improve help for CA Management openSUSE-11.2: New Priority Requester: Desirable Requested by: Michael Calmer (mcalmer) Description: This Module should offer a Hyperlink to far more text - possible online. Relations: - CA Management Module has Virtually No Help (novell/bugzilla/id: 515863) https://bugzilla.novell.com/show_bug.cgi?id=515863 -- openSUSE Feature: https://features.opensuse.org/306589

1 2

[openFATE 306590] Yast Common Server Certificate should support modify, delete, export
by fate_noreply＠suse.de 15 Jan '10

15 Jan '10

Feature added by: Michael Calmer (mcalmer) Feature #306590, revision 1 Title: Yast Common Server Certificate should support modify, delete, export openSUSE-11.2: New Priority Requester: Desirable Requested by: Michael Calmer (mcalmer) Description: More features for Common Server Certificate requested: * Ability to Modify/change the certificate * Ability to Delete * Ability to Export Relations: - Yast Common Server Certificate (novell/bugzilla/id: 510798) https://bugzilla.novell.com/show_bug.cgi?id=510798 -- openSUSE Feature: https://features.opensuse.org/306590

1 3

[openFATE 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 14 Jan '10

14 Jan '10

Feature changed by: Michael Calmer (mcalmer) Feature #305546, revision 15 Title: Support for NTLM authentication (proxy) in YaST and libzypp openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 18:02:44 reject reason: out of context for openSUSE. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ #2: Mark Muhlestein (mmuhlestein) (2010-01-13 18:10:39) Many of the engineers at Dell Computer in Austin want to use openSUSE 11.2 on their desktop machines. Dell uses a NTLM proxy on their corporate network so a lack of this functionality is keeping them from doing so. This group of engineers are very loyal SUSE/Novell folks who are trying very hard to help a SUSE desktop make inroads into Dell's corporate environment. Current number of engineers who cannot use the product is 50 - 60 On a side note, they see this a glaring problem. I don't know how many corporations use NTLM proxies but the gents at Dell seem to think it is quite a lot. #3: Katarina Machalkova (kmachalkova) (2010-01-14 15:03:36) I was wondering whether aria2c can handle NTLM auth. curl certainly does, but it's not our default downloader anymore. I googled a bit and found this table (http://curl.haxx.se/docs/comparison-table.html) and it doesn't look too positive :( #4: Duncan Mac-Vicar (dmacvicar) (2010-01-14 16:51:17) Because we are now using aria2 (however ZYpp stll can fall back to curl) I asked aria2 author if he planned something in the direction. He does not, however he will look into the protocol. The problem, appart of the time, is that he does not have a server to test. He pointed me to http://ntlmaps.sourceforge.net/ which allows to authenticate against a NTLM server acting as a normal proxy server. I have never tested this, but I wonder if companies really need support for this protocol in the tooling. + #5: Michael Calmer (mcalmer) (2010-01-14 16:57:35) (reply to #4) + I would say yes. I see sometimes logs from the registration where is a + proxy is in use with NTLM authentication. I think this is some kind of + Windows Server which is doing the authentication and automatically + support NTLM. If possible, we should have a way to support this. -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[openFATE 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 14 Jan '10

14 Jan '10

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305546, revision 14 Title: Support for NTLM authentication (proxy) in YaST and libzypp openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 18:02:44 reject reason: out of context for openSUSE. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ #2: Mark Muhlestein (mmuhlestein) (2010-01-13 18:10:39) Many of the engineers at Dell Computer in Austin want to use openSUSE 11.2 on their desktop machines. Dell uses a NTLM proxy on their corporate network so a lack of this functionality is keeping them from doing so. This group of engineers are very loyal SUSE/Novell folks who are trying very hard to help a SUSE desktop make inroads into Dell's corporate environment. Current number of engineers who cannot use the product is 50 - 60 On a side note, they see this a glaring problem. I don't know how many corporations use NTLM proxies but the gents at Dell seem to think it is quite a lot. #3: Katarina Machalkova (kmachalkova) (2010-01-14 15:03:36) I was wondering whether aria2c can handle NTLM auth. curl certainly does, but it's not our default downloader anymore. I googled a bit and found this table (http://curl.haxx.se/docs/comparison-table.html) and it doesn't look too positive :( + #4: Duncan Mac-Vicar (dmacvicar) (2010-01-14 16:51:17) + Because we are now using aria2 (however ZYpp stll can fall back to + curl) I asked aria2 author if he planned something in the direction. + He does not, however he will look into the protocol. The problem, + appart of the time, is that he does not have a server to test. + He pointed me to http://ntlmaps.sourceforge.net/ which allows to + authenticate against a NTLM server acting as a normal proxy server. I + have never tested this, but I wonder if companies really need support + for this protocol in the tooling. -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[openFATE 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 14 Jan '10

14 Jan '10

Feature changed by: Katarina Machalkova (kmachalkova) Feature #305546, revision 13 Title: Support for NTLM authentication (proxy) in YaST and libzypp openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 18:02:44 reject reason: out of context for openSUSE. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ #2: Mark Muhlestein (mmuhlestein) (2010-01-13 18:10:39) Many of the engineers at Dell Computer in Austin want to use openSUSE 11.2 on their desktop machines. Dell uses a NTLM proxy on their corporate network so a lack of this functionality is keeping them from doing so. This group of engineers are very loyal SUSE/Novell folks who are trying very hard to help a SUSE desktop make inroads into Dell's corporate environment. Current number of engineers who cannot use the product is 50 - 60 On a side note, they see this a glaring problem. I don't know how many corporations use NTLM proxies but the gents at Dell seem to think it is quite a lot. + #3: Katarina Machalkova (kmachalkova) (2010-01-14 15:03:36) + I was wondering whether aria2c can handle NTLM auth. curl certainly + does, but it's not our default downloader anymore. I googled a bit and + found this table (http://curl.haxx.se/docs/comparison-table.html) and + it doesn't look too positive :( -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[openFATE 307799] alpah
by fate_noreply＠suse.de 14 Jan '10

14 Jan '10

Feature added by: Dennis Kerley (dkerley) Feature #307799, revision 1 Title: alpah Buildservice: Unconfirmed Priority Requester: Important Requested by: Dennis Kerley (dkerley) Description: hime Internet filter -- openSUSE Feature: https://features.opensuse.org/307799

1 3