https://fedoraproject.org/w/api.php?action=feedcontributions&user=Gd&feedformat=atomFedoraProject - User contributions [en]2015-08-02T21:06:24ZUser contributionsMediaWiki 1.19.24https://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2013-05-14T14:53:06Z<p>Gd: /* Dependencies */</p>
<hr />
<div>&lt;!-- {{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}--&gt;<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19 | Fedora 19 ]] <br />
* Last updated: 2013-05-14<br />
* Percentage of completion: 100%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
* Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be able to leave all complexity of GSS_Init/Accept_sec_context() out of the kernel by upcalling to a daemon that does all the dirty work.<br />
* Isolation and privilege separation for user-mode applications. For example: letting HTTP servers use but not see the keytab entries for HTTP/* principals for accepting security contexts.<br />
* Possibly an ssh-agent-like SSH agent for GSS credentials -- a gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
Two major features that are planned to be achieved for Fedora19:<br />
* rpc.gssd, the NFS client application, should be enabled to use the gssproxy. It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.<br />
* gssproxy will offer Kerberos ticket renewal when user keytabs are available<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Gssproxy and all depending components are appropriately changed, all changes are part of the upstream projects and integrated in Fedora to provide a proxy infrastructure for GSSAPI. The gssproxy mechglue library is packaged and can be loaded from the GSSAPI version shipped on Fedora 19.<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use two test programs (shipped with the main tarball) in order to do basic testing of our implementation. With the mechglue interface is in place, any tests done for the GSSAPI interface itself allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel nfs server can benefit from the gssproxy interface in version 3.10.<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureAcceptedF19]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2013-05-14T14:51:35Z<p>Gd: /* How To Test */</p>
<hr />
<div>&lt;!-- {{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}--&gt;<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19 | Fedora 19 ]] <br />
* Last updated: 2013-05-14<br />
* Percentage of completion: 100%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
* Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be able to leave all complexity of GSS_Init/Accept_sec_context() out of the kernel by upcalling to a daemon that does all the dirty work.<br />
* Isolation and privilege separation for user-mode applications. For example: letting HTTP servers use but not see the keytab entries for HTTP/* principals for accepting security contexts.<br />
* Possibly an ssh-agent-like SSH agent for GSS credentials -- a gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
Two major features that are planned to be achieved for Fedora19:<br />
* rpc.gssd, the NFS client application, should be enabled to use the gssproxy. It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.<br />
* gssproxy will offer Kerberos ticket renewal when user keytabs are available<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Gssproxy and all depending components are appropriately changed, all changes are part of the upstream projects and integrated in Fedora to provide a proxy infrastructure for GSSAPI. The gssproxy mechglue library is packaged and can be loaded from the GSSAPI version shipped on Fedora 19.<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use two test programs (shipped with the main tarball) in order to do basic testing of our implementation. With the mechglue interface is in place, any tests done for the GSSAPI interface itself allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureAcceptedF19]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2013-05-14T14:47:29Z<p>Gd: /* Scope */</p>
<hr />
<div>&lt;!-- {{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}--&gt;<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19 | Fedora 19 ]] <br />
* Last updated: 2013-05-14<br />
* Percentage of completion: 100%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
* Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be able to leave all complexity of GSS_Init/Accept_sec_context() out of the kernel by upcalling to a daemon that does all the dirty work.<br />
* Isolation and privilege separation for user-mode applications. For example: letting HTTP servers use but not see the keytab entries for HTTP/* principals for accepting security contexts.<br />
* Possibly an ssh-agent-like SSH agent for GSS credentials -- a gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
Two major features that are planned to be achieved for Fedora19:<br />
* rpc.gssd, the NFS client application, should be enabled to use the gssproxy. It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.<br />
* gssproxy will offer Kerberos ticket renewal when user keytabs are available<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Gssproxy and all depending components are appropriately changed, all changes are part of the upstream projects and integrated in Fedora to provide a proxy infrastructure for GSSAPI. The gssproxy mechglue library is packaged and can be loaded from the GSSAPI version shipped on Fedora 19.<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureAcceptedF19]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2013-05-14T14:43:58Z<p>Gd: /* Current status */</p>
<hr />
<div>&lt;!-- {{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}--&gt;<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19 | Fedora 19 ]] <br />
* Last updated: 2013-05-14<br />
* Percentage of completion: 100%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
* Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be able to leave all complexity of GSS_Init/Accept_sec_context() out of the kernel by upcalling to a daemon that does all the dirty work.<br />
* Isolation and privilege separation for user-mode applications. For example: letting HTTP servers use but not see the keytab entries for HTTP/* principals for accepting security contexts.<br />
* Possibly an ssh-agent-like SSH agent for GSS credentials -- a gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
Two major features that are planned to be achieved for Fedora19:<br />
* rpc.gssd, the NFS client application, should be enabled to use the gssproxy. It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.<br />
* gssproxy will offer Kerberos ticket renewal when user keytabs are available<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureAcceptedF19]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2013-01-24T11:31:13Z<p>Gd: </p>
<hr />
<div>&lt;!-- {{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}--&gt;<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19 | Fedora 19 ]] <br />
* Last updated: 2013/01/23<br />
* Percentage of completion: 95%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytab entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
Two major features that are planned to be achieved for Fedora19:<br />
<br />
- rpc.gssd, the NFS client application, should be enabled to use the gssproxy. <br />
It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.<br />
<br />
- gssproxy will offer Kerberos ticket renewal when user keytabs are available<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2013-01-23T18:57:27Z<p>Gd: small update for f19</p>
<hr />
<div>&lt;!-- {{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}--&gt;<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/19 | Fedora 19 ]] <br />
* Last updated: 2013/01/23<br />
* Percentage of completion: 95%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytab entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
Two major features are planned to be achieved for Fedora19 is:<br />
<br />
- rpc.gssd, the NFS client application, should be enabled to use the gssproxy. It will be possible to aquire tickets for kerberized NFS mounts given user keytabs.<br />
- gssproxy will offer Kerberos ticket renewal when user keytabs are available<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/Samba4Features/Samba42012-07-20T15:54:05Z<p>Gd: /* Detailed Description */</p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= Samba 4.0 &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
<br />
The Samba Team is working on a release of Samba4. on Monday, 16th of July 2012, Samba 4.0 beta4 has been released. This is important<br />
milestone in a more than 8 years of Samba 4 development. This page attempts to explain what will be and will not be available in<br />
Fedora.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:Asn| Andreas Schneider]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: asn@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012-07-18<br />
* Percentage of completion: 99%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
Samba 4 is a combined set of daemons, client utilities, and Python<br />
bindings that allow communicating using SMB1, SMB2, and soon SMB3<br />
protocols. It also implements Active Directory domain controller (DC)<br />
functionality as an integrated Kerberos DC, LDAP server, DNS server, <br />
and SMB/CIFS server.<br />
<br />
The following is a detailed description of the Kerberos problem that we have in Fedora.<br />
<br />
Samba 4 AD DC functionality relies heavily on Heimdal Kerberos<br />
implementation. Samba 4 includes the embedded Heimdal, if your system<br />
misses it, like we have in Fedora. When embedded Heimdal is in use,<br />
all Samba 4 code is compiled against this Kerberos implementation,<br />
including client side libraries and tools, and traditional file serving<br />
smbd daemon we know as 'samba' package in Fedora.<br />
<br />
Fedora uses MIT Kerberos implementation, both server and client side.<br />
Heimdal and MIT Kerberos are targetting to implement the same Kerberos V<br />
protocol but have their own extensions API and certain semantical<br />
differences. They also have slightly different meaning to Kerberos<br />
credential cache files format where Kerberos-aware applications store<br />
their Kerberos keys. While this is not an issue for client-server <br />
communication over a network (a Heimdal client does talk the same<br />
Kerberos V protocol that MIT Kerberos server understands and vice<br />
versa), interoperability of the client or server code using the same<br />
credential cache files on the same system is much less supported for<br />
advanced features like S4U2Proxy and S4U2Self.<br />
<br />
It is generally not advisable to load two different API implementations<br />
into the same address space either. When the rest of the system<br />
libraries is compiled against MIT Kerberos, use of them within Samba 4<br />
code brings in MIT Kerberos as well. This happens, for example, when<br />
linking against OpenLDAP client libraries and using SASL authentication.<br />
<br />
As part of work we are doing on FreeIPA v3, we have made possible to<br />
compile Samba 4 code against MIT Kerberos implementation. Unfortunately,<br />
MIT Kerberos does not give option of embedding Kerebros KDC server within<br />
another process which is required for Samba 4 AD DC functionality. Thus,<br />
when compiled with MIT Kerberos, Samba 4 currently does not provide Active<br />
Directory Domain Controller functionality at all, only client side<br />
libraries and tools to the extent that does not involve AD DC<br />
operations. Also, smbd is compiled against MIT Kerberos and provides<br />
functionality equivalent to what is provided by Samba 3's smbd.<br />
<br />
We are intending to make possible use of AD DC functionality with MIT<br />
Kerberos but this is longer term project that requires cooperation<br />
between Samba, MIT, and FreeIPA.<br />
<br />
For GNU/Linux-based clients FreeIPA already provides functionality<br />
similar to the one of Active Directory. With FreeIPA v3 we'll have<br />
cross-realm trusts support with Active Directory that will allow<br />
seamlessly integrating GNU/Linux-based machines into existing AD-based<br />
infrastructure. You can get details about implementation from our talk<br />
at SambaXP 2012 conference (http://abbra.fedorapeople.org/freeipa.pdf) and<br />
earlier roadmap talk at Fedora Devconf in Brno in February 2012<br />
(http://blip.tv/fedoracz/dmitripal-idenitymanagementroadmap-6071539)<br />
<br />
One consequence of Samba 4 built with MIT Kerberos is that Openchange<br />
server code will not be working in Fedora either. Openchange server code<br />
requires working Samba 4 DC server with proper AD provisioning. This only<br />
affects server side and does not affect Openchange client side support<br />
which is used in Evolution MAPI plugin, which will continue to work.<br />
<br />
Rawhide is already providing Samba 4 built with MIT Kerberos,<br />
and Openchange package was modified to include only client side support.<br />
The latter also submitted and merged to Openchange upstream.<br />
<br />
What is available in Rawhide right now?<br />
<br />
* samba4-* 4.0.0-128.fc18.beta4 packages are built against system-wide MIT Kerberos libraries. These packages are made conflicting with samba-* packages in areas where they provide the same binaries and/or libraries. You don't need to install samba4-* packages unless you want to use Evolution MAPI plugin and (soon FreeIPA v3 server).<br />
<br />
* openchange is built to provide client-side libraries to allow Evolution MAPI plugin to work.<br />
<br />
* Evolution MAPI plugin is rebuilt against new openchange build.<br />
<br />
What will not be available in Rawhide in time for Fedora 18?<br />
<br />
* Samba 4 AD DC implementation<br />
<br />
What about samba and samba4 packages?<br />
<br />
As samba4 is a superset of Samba 3 packages in Fedora, we are also<br />
considering to discuss renaming samba4 back to samba. As all existing<br />
API and ABI for smbd/nmbd/winbindd and libsmbclient library will be the<br />
same, the switch is not going to be problematic. However, there is still<br />
need to stabilize code through beta and pre-releases before doing that.<br />
<br />
We also intend to work with upstream and other distributions on making<br />
common set of instructions on configuring and setting up different<br />
facets of Samba (AD DC, file server, member server, ...).<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The benefit for Fedora will be that we will provide a Samba file server with SMB3 support and support for FreeIPA trusted domains. The daemons are still the same but provide the latest features of the Samba file server and id mapping.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
The work is mostly done. We need to decide if we rename the package from samba4 to samba. The other thing is if we still want to provide 3.6 packages.<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Samba provides a full features test suite which covers all of it main features. Beside that FreeIPA need to be able to establish a trust relationship with Active directory using the samba4-libs, python bindings and the smbd daemon.<br />
<br />
HOWTO:<br />
0. You need physical hardware or virtual machines with a Windows Active Directory Server installed, a Windows Client installation and a Fedora installation.<br />
1. You install the AD server and created users, then you join the Windows client to AD and setup FreeIPA.<br />
2. Create a two way trust relationship using ipa-trust-install.<br />
3. Login to the Windows client and use putty to connect to the FreeIPA server via SSH.<br />
4. This should work without putty asking you for a password.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
Users will enjoy the features for the new SMB protocols and FreeIPA user will be happy to be able to created trust relationships with Active Directory.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
FreeIPA and OpenChange depend on libraries provided by Samba4. The samba4-libs package can be installed on the system without any conflict to other Samba packages. The FreeIPA feature for trust relationships between Active Directory requires the samba4 package in addition. This means it conflicts with the samba package.<br />
<br />
As this package doesn't provide the DC functionality yet cause of MIT KRB5 OpenChange is not able to provide the server component.<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the Samba4 is not fully complete by the end of the final development freeze, Fedora can still ship it. The samba4-libs package which is needed by OpenChange can be installed without any conflicts with the samba (Samba 3.6) packages. All other packages conflict with the samba packages.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
* [[ https://wiki.samba.org/index.php/Main_Page | The Samba Wiki ]]<br />
* The Procotol documention is available at the [[ http://msdn.microsoft.com/en-us/library/dd208104%28PROT.10%29.aspx | Microsoft Open Specifications Portal ]]<br />
* The Samba4 Manpages<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* Samba 4.0 beta supports the new SMB2.2 and SMB3 protocols.<br />
<br />
* Samba 4.0 beta ships with a LSA Service Daemon for FreeIPA trust relationship support.<br />
<br />
* A new scripting interface has been added to Samba 4, allowing Python programs to interface to Samba's internals, and many tools and internal workings of the DC code is now implemented in python.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Samba4]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/Samba4Features/Samba42012-07-20T15:44:33Z<p>Gd: /* Summary */</p>
<hr />
<div>&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= Samba 4.0 &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
<br />
The Samba Team is working on a release of Samba4. on Monday, 16th of July 2012, Samba 4.0 beta4 has been released. This is important<br />
milestone in a more than 8 years of Samba 4 development. This page attempts to explain what will be and will not be available in<br />
Fedora.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:Asn| Andreas Schneider]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: asn@redhat.com<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012-07-18<br />
* Percentage of completion: 99%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
Samba 4 is a combined set of daemons, client utilities, and Python<br />
bindings that allow communicating using SMB1, SMB2, and soon SMB3<br />
protocols. It also implements Active Directory domain controller (DC)<br />
functionality as an integrated Kerberos DC, LDAP server, DNS server, <br />
and SMB/CIFS server.<br />
<br />
Samba 4 AD DC functionality relies heavily on Heimdal Kerberos<br />
implementation. Samba 4 includes the embedded Heimdal, if your system<br />
misses it, like we have in Fedora. When embedded Heimdal is in use,<br />
all Samba 4 code is compiled against this Kerberos implementation,<br />
including client side libraries and tools, and traditional file serving<br />
smbd daemon we know as 'samba' package in Fedora.<br />
<br />
Fedora uses MIT Kerberos implementation, both server and client side.<br />
Heimdal and MIT Kerberos are targetting to implement the same Keberos V<br />
protocol but have their own extensions API and certain semantical<br />
differences. They also have slightly different meaning to Kerberos<br />
credential cache files format where Kerberos-aware applications store<br />
their Kerberos keys. While this is not an issue for client-server <br />
communication over a network (a Heimdal client does talk the same<br />
Kerberos V protocol that MIT Kerberos server understands and vice<br />
versa), interoperability of the client or server code using the same<br />
credential cache files on the same system is much less supported for<br />
advanced features like S4U2Proxy and S4U2Self.<br />
<br />
It is generally not advisable to load two different API implementations<br />
into the same address space either. When the rest of the system<br />
libraries is compiled against MIT Kerberos, use of them within Samba 4<br />
code brings in MIT Kerberos as well. This happens, for example, when<br />
linking against OpenLDAP client libraries and using SASL authentication.<br />
<br />
As part of work we are doing on FreeIPA v3, we have made possible to<br />
compile Samba 4 code against MIT Kerberos implementation. Unfortunately,<br />
MIT Kerberos does not give option of embedding Kerebros KDC server within<br />
another process which is required for Samba 4 AD DC functionality. Thus,<br />
when compiled with MIT Kerberos, Samba 4 currently does not provide Active<br />
Directory Domain Controller functionality at all, only client side<br />
libraries and tools to the extent that does not involve AD DC<br />
operations. Also, smbd is compiled against MIT Kerberos and provides<br />
functionality equivalent to what is provided by Samba 3's smbd.<br />
<br />
We are intending to make possible use of AD DC functionality with MIT<br />
Kerberos but this is longer term project that requires cooperation<br />
between Samba, MIT, and FreeIPA.<br />
<br />
For GNU/Linux-based clients FreeIPA already provides functionality<br />
similar to the one of Active Directory. With FreeIPA v3 we'll have<br />
cross-realm trusts support with Active Directory that will allow<br />
seamlessly integrating GNU/Linux-based machines into existing AD-based<br />
infrastructure. You can get details about implementation from our talk<br />
at SambaXP 2012 conference (http://abbra.fedorapeople.org/freeipa.pdf) and<br />
earlier roadmap talk at Fedora Devconf in Brno in February 2012<br />
(http://blip.tv/fedoracz/dmitripal-idenitymanagementroadmap-6071539)<br />
<br />
One consequence of Samba 4 built with MIT Kerberos is that Openchange<br />
server code will not be working in Fedora either. Openchange server code<br />
requires working Samba 4 DC server with proper AD provisioning. This only<br />
affects server side and does not affect Openchange client side support<br />
which is used in Evolution MAPI plugin, which will continue to work.<br />
<br />
Rawhide is already providing Samba 4 built with MIT Kerberos,<br />
and Openchange package was modified to include only client side support.<br />
The latter also submitted and merged to Openchange upstream.<br />
<br />
What is available in Rawhide right now?<br />
<br />
* samba4-* 4.0.0-128.fc18.beta4 packages are built against system-wide MIT Kerberos libraries. These packages are made conflicting with samba-* packages in areas where they provide the same binaries and/or libraries. You don't need to install samba4-* packages unless you want to use Evolution MAPI plugin and (soon FreeIPA v3 server).<br />
<br />
* openchange is built to provide client-side libraries to allow Evolution MAPI plugin to work.<br />
<br />
* Evolution MAPI plugin is rebuilt against new openchange build.<br />
<br />
What will not be available in Rawhide in time for Fedora 18?<br />
<br />
* Samba 4 AD DC implementation<br />
<br />
What about samba and samba4 packages?<br />
<br />
As samba4 is a superset of Samba 3 packages in Fedora, we are also<br />
considering to discuss renaming samba4 back to samba. As all existing<br />
API and ABI for smbd/nmbd/winbindd and libsmbclient library will be the<br />
same, the switch is not going to be problematic. However, there is still<br />
need to stabilize code through beta and pre-releases before doing that.<br />
<br />
We also intend to work with upstream and other distributions on making<br />
common set of instructions on configuring and setting up different<br />
facets of Samba (AD DC, file server, member server, ...).<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The benefit for Fedora will be that we will provide a Samba file server with SMB3 support and support for FreeIPA trusted domains. The daemons are still the same but provide the latest features of the Samba file server and id mapping.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
The work is mostly done. We need to decide if we rename the package from samba4 to samba. The other thing is if we still want to provide 3.6 packages.<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Samba provides a full features test suite which covers all of it main features. Beside that FreeIPA need to be able to establish a trust relationship with Active directory using the samba4-libs, python bindings and the smbd daemon.<br />
<br />
HOWTO:<br />
0. You need physical hardware or virtual machines with a Windows Active Directory Server installed, a Windows Client installation and a Fedora installation.<br />
1. You install the AD server and created users, then you join the Windows client to AD and setup FreeIPA.<br />
2. Create a two way trust relationship using ipa-trust-install.<br />
3. Login to the Windows client and use putty to connect to the FreeIPA server via SSH.<br />
4. This should work without putty asking you for a password.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
Users will enjoy the features for the new SMB protocols and FreeIPA user will be happy to be able to created trust relationships with Active Directory.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
FreeIPA and OpenChange depend on libraries provided by Samba4. The samba4-libs package can be installed on the system without any conflict to other Samba packages. The FreeIPA feature for trust relationships between Active Directory requires the samba4 package in addition. This means it conflicts with the samba package.<br />
<br />
As this package doesn't provide the DC functionality yet cause of MIT KRB5 OpenChange is not able to provide the server component.<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the Samba4 is not fully complete by the end of the final development freeze, Fedora can still ship it. The samba4-libs package which is needed by OpenChange can be installed without any conflicts with the samba (Samba 3.6) packages. All other packages conflict with the samba packages.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
* [[ https://wiki.samba.org/index.php/Main_Page | The Samba Wiki ]]<br />
* The Procotol documention is available at the [[ http://msdn.microsoft.com/en-us/library/dd208104%28PROT.10%29.aspx | Microsoft Open Specifications Portal ]]<br />
* The Samba4 Manpages<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* Samba 4.0 beta supports the new SMB2.2 and SMB3 protocols.<br />
<br />
* Samba 4.0 beta ships with a LSA Service Daemon for FreeIPA trust relationship support.<br />
<br />
* A new scripting interface has been added to Samba 4, allowing Python programs to interface to Samba's internals, and many tools and internal workings of the DC code is now implemented in python.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Samba4]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-13T12:50:34Z<p>Gd: /* Release Notes */</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* gssproxy is an opensource project that aims to improve GSSAPI usage from both the kernel (for authenticating remote file system access) as well as user-space applications. It does provide fine-grained access control on Kerberos keytab access and it overcomes various limitations the kernel had when dealing with Kerberos tickets.<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-12T15:48:47Z<p>Gd: /* Comments and Discussion */</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* TBD<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/gssproxy]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-12T15:48:08Z<p>Gd: /* GSS Proxy */</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* TBD<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Your_Feature_Name]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeatureReadyForWrangler]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-12T15:44:36Z<p>Gd: /* Release Notes */</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
* TBD<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Your_Feature_Name]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-03T14:02:23Z<p>Gd: Add MIT wiki link for doc section</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
<br />
* The gssproxy project wiki page of the MIT Consortium: [http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI]<br />
* Protocol Documentation is available online as well: [https://fedorahosted.org/gss-proxy/].<br />
<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
*<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Your_Feature_Name]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-02T14:22:37Z<p>Gd: /* Summary */</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
The main purpose of this project is to replace rpc.svcgssd(8), the server-side rpcsec_gss daemon.<br />
<br />
The gss-proxy consists of a standardized RPC protocol, a client and server implementation with other future components. The gss-proxy protocol allows proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
* Currently there is only Protocol Documentation available online: [https://fedorahosted.org/gss-proxy/].<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
*<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Your_Feature_Name]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/Features/gss-proxyFeatures/gss-proxy2012-07-02T14:10:20Z<p>Gd: Created page with &quot;{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }} &lt;!-- All fields on this form are required t...&quot;</p>
<hr />
<div>{{admon/note | All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed }}<br />
<br />
<br />
&lt;!-- All fields on this form are required to be accepted by FESCo.<br />
We also request that you maintain the same order of sections so that all of the feature pages are uniform. --&gt;<br />
<br />
&lt;!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --&gt;<br />
<br />
= GSS Proxy &lt;!-- The name of your feature --&gt; =<br />
<br />
== Summary ==<br />
&lt;!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --&gt;<br />
This project is about creating a gss-proxy protocol to allow proxying of GSSAPI initiation and authentication.<br />
<br />
== Owner ==<br />
&lt;!--This should link to your home wiki page so we know who you are--&gt;<br />
* Name: [[User:simo| Simo Sorce]]<br />
<br />
&lt;!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--&gt;<br />
* Email: &lt;ssorce@redhat.com&gt;<br />
<br />
* Name: [[User:gd| Günther Deschner]]<br />
* Email: &lt;gdeschner@redhat.com&gt;<br />
<br />
== Current status ==<br />
* Targeted release: [[Releases/18 | Fedora 18 ]] <br />
* Last updated: 2012/06/30<br />
* Percentage of completion: 90%<br />
<br />
&lt;!-- CHANGE THE &quot;FedoraVersion&quot; TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --&gt;<br />
<br />
== Detailed Description ==<br />
&lt;!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --&gt;<br />
<br />
The goal is to have a GSS-API proxy, with standardizable protocol and a<br />
[somewhat portable] reference client and server implementation. There<br />
are several motivations for this some of which are:<br />
<br />
- Kernel-mode GSS-API applications (CIFS, NFS, AFS, ...) need to be<br />
able to leave all complexity of GSS_Init/Accept_sec_context() out of<br />
the kernel by upcalling to a daemon that does all the dirty work.<br />
<br />
- Isolation and privilege separation for user-mode applications. For<br />
example: letting HTTP servers use but not see the keytabe entries for<br />
HTTP/* principals for accepting security contexts.<br />
<br />
- Possibly an ssh-agent-like SSH agent for GSS credentials -- a<br />
gss-agent.<br />
<br />
In order to use the gssproxy only the gssproxy daemon has to be started at boottime. Once this is done, the GSSAPI mechglue library will make sure all GSSAPI calls issued by an application are directed to the gssproxy service transparently. Depending on the configuration of the system, the gssproxy daemon will then allow or disallow access to cryptographic keys stored in keytabs on the system.<br />
<br />
<br />
== Benefit to Fedora ==<br />
&lt;!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--&gt;<br />
<br />
The key benefit for Fedora will be that we can provide more fine grained control over controlling access of applications to highly sensible cryptographic key material (keytabs). This in general improves security on the system.<br />
<br />
== Scope ==<br />
&lt;!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--&gt;<br />
<br />
Work on the GSSAPI mechglue library is in progress but is currently not finished.<br />
<br />
In order to properly load our mechglue library, some modifications to the system GSSAPI/Kerberos library (MIT) are required. Work on this has well progressed and is coordinated with upstream (MIT).<br />
<br />
== How To Test ==<br />
&lt;!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be. <br />
<br />
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.<br />
<br />
A good &quot;how to test&quot; should answer these four questions:<br />
<br />
0. What special hardware / data / etc. is needed (if any)?<br />
1. How do I prepare my system to test this feature? What packages<br />
need to be installed, config files edited, etc.?<br />
2. What specific actions do I perform to check that the feature is<br />
working like it's supposed to?<br />
3. What are the expected results of those actions?<br />
--&gt;<br />
<br />
Currently we use a test program (shipped with the main tarball) in order to do basic testing of our implementation. Once the mechglue interface is in place, any tests done for the GSSAPI interface itself would allow to test the gssproxy as well. <br />
<br />
For the current testing you need to have a working KDC, one needs to create a keytab and gssproxy needs to be properly installed and configured.<br />
<br />
== User Experience ==<br />
&lt;!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. --&gt;<br />
<br />
The usage of the gssproxy protocol and implementation is completely transparent for the user. Also applications do not need to be modified in order to benefit from the gssproxy.<br />
<br />
== Dependencies ==<br />
&lt;!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --&gt;<br />
<br />
The kernel will use the gssproxy interface.<br />
<br />
<br />
== Contingency Plan ==<br />
&lt;!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as &quot;None necessary, revert to previous release behaviour.&quot; Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --&gt;<br />
<br />
In case the gssproxy is not complete by the end of the final development freeze, Fedora can just decide to not ship it.<br />
<br />
== Documentation ==<br />
&lt;!-- Is there upstream documentation on this feature, or notes you have written yourself? Link to that material here so other interested developers can get involved. --&gt;<br />
* Currently there is only Protocol Documentation available online: [https://fedorahosted.org/gss-proxy/].<br />
<br />
== Release Notes ==<br />
&lt;!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --&gt;<br />
&lt;!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --&gt;<br />
*<br />
<br />
== Comments and Discussion ==<br />
* See [[Talk:Features/Your_Feature_Name]] &lt;!-- This adds a link to the &quot;discussion&quot; tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --&gt;<br />
<br />
<br />
[[Category:FeaturePageIncomplete]]<br />
&lt;!-- When your feature page is completed and ready for review --&gt;<br />
&lt;!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --&gt;<br />
&lt;!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--&gt;<br />
&lt;!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --&gt;</div>Gdhttps://fedoraproject.org/wiki/User:GdUser:Gd2012-06-29T14:39:08Z<p>Gd: Created page with &quot;= Günther Deschner = &lt;!-- An (optional) photo of yourself (image attached to the page). --&gt; &lt;!-- Comment out the following line if you don't have one. {{ Template:floatright/|...&quot;</p>
<hr />
<div>= Günther Deschner =<br />
<br />
&lt;!-- An (optional) photo of yourself (image attached to the page).<br />
--&gt;<br />
&lt;!-- Comment out the following line if you don't have one.<br />
<br />
{{ Template:floatright/| [[Image:GuntherDeschner_FirstnameLastname-head.png]]<br />
}}--&gt;<br />
<br />
* Samba Team member &lt;gd samba org&gt;<br />
* Senior Software Engineer at Red Hat Inc. &lt;gdeschner redhat com&gt;<br />
<br />
== Contact ==<br />
<br />
* '''Email''': [[MailTo(gdeschner AT redhat DOT com)] (moin encodes email addresses properly to anonymous users)<br />
* '''IRC''': gd<br />
* '''GPG key''': Your key ID and/or signature<br />
* '''Fedora Account''': gd<br />
<br />
== Activities within Fedora ==<br />
<br />
* maintainer of samba<br />
* Work upstream on samba, gss-proxy</div>Gdhttps://fedoraproject.org/wiki/Archive:FUDCon:Berlin_2009_attendeesArchive:FUDCon:Berlin 2009 attendees2009-06-09T16:10:51Z<p>Gd: </p>
<hr />
<div>This is the registration page for [[FUDConBerlin2009]].<br />
<br />
'''Please add your name to the list if you will attend.''' Also, please indicate the following:<br />
* Put an '''X''' in the ''$$$'' column if you need funding to attend. We'll use these answers to help figure out budgeting for the event.<br />
* Put your T-shirt size in the ''Size'' column, so we can have an idea about what sizes to have available.<br />
* We request your email address in case we need to send announcements about FUDCon in channels other than fedora-announce-list and Planet Fedora.<br />
<br />
{{Admon/note | Budget is tight! | ''We typically cannot fund everyone who wants to attend.'' We will make every effort to have FUDCon be as affordable as possible. [[FUDCon:Berlin_2009_lodging|Hotel information is now available]].}}<br />
<br />
{|class=&quot;wikimedia sortable&quot; style=&quot;t1&quot; rowclass=&quot;th&quot;<br />
! Number !! Name !! Funding? !! Size !! Email address (if not on your wiki page) !! Notes<br />
|-<br />
| 001 || [[MaxSpevack]] || || L || ||<br />
|-<br />
| 002 || [[FabianAffolter]] || || XL || ||<br />
|-<br />
| 003 || [[RadekVokal]] || X || L || ||<br />
|-<br />
| 004 || [[User:Red|Sandro Mathys]] || || M || ||<br />
|-<br />
| 005 || [[GeroldKassube]] || X || XXL || ||<br />
|-<br />
| 006 || [[User:Pfrields|Paul W. Frields]] || || XXL || ||<br />
|-<br />
| 007 || [[User:Robert|Robert Scheck]] || X || XXL || ||<br />
|-<br />
| 008 || [[User:Mmahut|Marek Mahut]] || X || XL || ||<br />
|-<br />
| 009 || [[LennartPoettering]] || || L || || I live in Berlin<br />
|-<br />
| 010 || [[User:Glezos|Dimitris Glezos]] || X || M || || Staying at a friend.<br />
|-<br />
| 011 || [[User:Cwickert|Christoph Wickert]] || X || L || ||<br />
|-<br />
| 012 || [[ChristianGrams]] || || XXL || || Staying with family<br />
|-<br />
| 013 || [[User:Kanarip|Jeroen van Meeuwen]] || || XL || || Good to be #13! Awesome!<br />
|-<br />
| 014 || [[User:biertie|Bert Desmet]] || Helpful for lodging || XL || || <br />
|-<br />
| 015 || [[User:spot|Tom Callaway]] || X || XXL || || Max said he'd pay for me to be there. :)<br />
|-<br />
| 016 || [[User:ynemoy |Yaakov Nemoy]] || Helpful || M || || Moar Cowbell!<br />
|-<br />
| 017 || [[User:ixs | Andreas Thienemann]] || || XXL || || Yeah, sweet sixteen.<br />
|-<br />
| 018 || [[User:baard | Stefan Hartsuiker]] || || XXL || ||<br />
|-<br />
| 019 || [[User:olea | Ismael Olea]] || Helpful || XXL || ||<br />
|-<br />
| 020 || [[User:thl | Thorsten Leemhuis]] || Helpful for lodging || M || || No ticket needed for LinuxTag <br />
|-<br />
| 021 || [[FrancescoCrippa]] || || XL || ||<br />
|-<br />
| 022 || [[User:Bokal]] || X || M || || I live in Bremen<br />
|-<br />
| 023 || [[User:Lkundrak|Lubomir Rintel]] || X || XXL || ||<br />
|-<br />
| 024 || [[User:Lfoppiano|Luca Foppiano]] || X || M || ||<br />
|-<br />
| 025 || [[User:Tiagovieira|Tiago Vieira]] || X || XL || || <br />
|-<br />
| 026 || [[User:Lazzurs|Rob Lazzurs]] || || XXL || ||<br />
|-<br />
| 027 || [[User:e1luca|Ewan Luca]] || X || XXL || ||<br />
|-<br />
| 028 || [[User:linville|John W. Linville]] || X || XXL || ||<br />
|-<br />
| 029 || [[User:romal|Robert M. Albrecht]] || || XL || ||<br />
|-<br />
| 030 || [[User:twoerner|Thomas Woerner]] || || M || ||<br />
|-<br />
| 031 || [[User:wonderer|Henrik Heigl]] || X || XL || ||<br />
|-<br />
| 033 || [[User:nicubunu|Nicu Buculei]] || X || XL || || Trying to get a few more contributors from my country to participate<br />
|-<br />
| 034 || [[User:crossovo|Daniel Kretschmer]] || Helpful || M || ||<br />
|-<br />
| 035 || [[User:pknirsch|Phil Knirsch]] || || XL || ||<br />
|-<br />
| 036 || Luiz Davi L Martins || X || XXL || luizdavilm@gmail.com || I live in Mannheim (near Frankfurt).<br />
|-<br />
| 037 || [[User:johannbg|Johann B.]] || X || XL || ||<br />
|-<br />
| 038 || [[User:aarapov|Anton Arapov]] || X || L || ||<br />
|-<br />
| 039 || [[User:Giangy|Gianluca Varisco]] || X || XL || ||<br />
|-<br />
| 040 || [[User:mjung|Marko Jung]] || || XL || || ''I think I will be around ;-)''<br />
|-<br />
| 041 || [[FlorianFesti | Florian Festi]] || || XXXL || || Damn, one too early for 42<br />
|-<br />
| 042 || [[User:Nphilipp|Nils Philippsen]] || || XL || || Argh, one too late for 41<br />
|-<br />
| 043 || [[User:Mmaslano|Marcela Mašláňová]] || X || S || || <br />
|-<br />
| 044 || [[User:mjg|Michael J Gruber]] || || XXL || || Will probably stay with family.<br />
|-<br />
| 045 || [[User:jens|Jens Kühnel]] || would be nice || M || || <br />
|-<br />
| 046 || [[User:harald|Harald Hoyer]] || || L || || <br />
|-<br />
| 047 || Denys Vlasenko || || XL || ||<br />
|-<br />
| 049 || Armin Singer || || XL || fudconguest@equicon.de ||<br />
|-<br />
| 050 || [[SebastianDziallas]] || X || L || ||<br />
|-<br />
| 051 || [[HendrikRichter]] || || M || hendrikr@gnome.org || <br />
|-<br />
| 052 || [[User:kraxel|Gerd Hoffmann]] || || M || || Friday and Saturday only<br />
|-<br />
| 053 || [[User:Bochecha|Mathieu Bridon]] || X || M || || No ticket needed for LinuxTag, going only to FUDcon<br />
|-<br />
| 054 || [[User:Nashella|Nadège Michel]] || || || || will not come.<br />
|-<br />
| 055 || [[User:Gbraad|Gerard Braad]] || X || || || Cancelled: Not available :-(, will be in Venice instead.<br />
|-<br />
| 056 || [[User:Pbrobinson|Peter Robinson]] || Helpful || L || || Prob arrive Thurs 25th.<br />
|-<br />
| 057 || [[User:Pvrabec|Peter Vrabec]] || X || M || || <br />
|-<br />
| 058 || [[User:Libbe|Espen Stefansen]] || Helpful || XL || || <br />
|-<br />
| 059 || [[User:Hans|Hans-Joachim Picht]] || || L || hans@fedoraproject.org || <br />
|-<br />
| 060 || Steffen Maier || || XL || smaier at users.sourceforge.net || <br />
|-<br />
| 061 || Renke Brausse || || M || rbrausse /at/ gmx.net || <br />
|-<br />
| 062 || Philipp Hanselmann || || M || philipp.hanselmann id.ethz.ch || <br />
|-<br />
| 063 || [[JoshBressers]] || || L || ||<br />
|-<br />
| 064 || [[MarkCox]] || || L || ||<br />
|-<br />
| 065 || [[User:Eteo|Eugene Teo]] || || XXL || ||<br />
|-<br />
| 066 || [[User:mdious|Murray McAllister]] || || M || ||<br />
|-<br />
| 067 || [[User:Jlieskov|Ján Lieskovský]] || || L || ||<br />
|-<br />
| 068 || [[User:vdanen|Vincent Danen]] || || L || ||<br />
|-<br />
| 069 || Johannes Berg || - || S || johannes -at- sipsolutions.net || wireless mini summit (will be there 25 afternoon - 28 afternoon)<br />
|-<br />
| 070 || [[User:choeger|Christoph Höger]] || || L || choeger@cs.tu-berlin.de || live in berlin<br />
|-<br />
| 071 || [[User:schonef|Marc Schoenefeld]] || || L || || 2 * 42 - 13 <br />
|-<br />
| 072 || Rainer Schaupp || - || XL || rschaupp -ät- kreativhaus-tpz.de || I live in B<br />
|-<br />
| 073 || Bob Copeland || || L || me -at- bobcopeland.com || @ wireless mini summit<br />
|-<br />
| 074 || Ivo van Doorn || || XL || IvDoorn -at- gmail.com || @ wireless mini summit<br />
|-<br />
| 075 || Luis Correia || X || XL || luis.f.correia -at- gmail.com || @ wireless mini summit<br />
|-<br />
| 076 || swamych || X || M || swamych -at- gmail.com ||<br />
|-<br />
| 077 || [[User:jpmcd|John P. McDonough]] || || XL || jp -at- is-sixsigma.com ||<br />
|-<br />
| 078 || [[User:duffy|Máirín Duffy]] || X || S or XS || duffy *~*at*~* redhat *~*dot*~* com || I &lt;3 pink ponies<br />
|-<br />
| 079 || Thorsten Scherf || || L || tscherf -at- redhat.com || <br />
|-<br />
| 080 || Hin-Tak Leung || X || L || htl10 -at- users.sourceforge.net || @ wireless mini summit<br />
|-<br />
| 081 || [[User:Plautrba|Petr Lautrbach]] || X || L || ||<br />
|-<br />
| 082 || [[User:Heffer|Felix Kaechele]] || would be great || M || ||<br />
|-<br />
| 083 || [[User:jnovy|Jindřich Nový]] || X || L || ||<br />
|-<br />
| 084 || [[User:jskala|Jiří Skála]] || X || XL || ||<br />
|-<br />
| 085 || [[User:mapleoin|Ionuț Arțăriși]] || X || L ||<br />
|-<br />
| 086 || [[User:jsafrane|Jan Šafránek]] || X || L || ||<br />
|-<br />
| 087 || [[User:tsantore|Tristan Santore]] || || M || TSantore -at- fedoraproject.org ||<br />
|-<br />
| 088 || Felix Fietkau || || L || nbd -at- openwrt.org || @ wireless mini summit<br />
|-<br />
| 089 || Kern Sibbald || || L || kern -at- baculasystems.com || <br />
|-<br />
| 090 || Sumit Bose || || L || sbose -at- redhat.com || live near Berlin<br />
|-<br />
| 091 || [[User:bitshaka|Matthias Adler]] || || M || || live in berlin<br />
|-<br />
| 092 || Kalle Valo || || XXL || kalle.valo@iki.fi || @ wireless mini summit<br />
|-<br />
| 093 || [[User:andreasr|Andreas Rau]] || || L || Andreas.Rau@unibas.ch || <br />
|-<br />
| 094 || Niels Weber || || M || nath -at- wsjg.de || live in Berlin<br />
|-<br />
| 095 || Jouni Malinen || || || j@w1.fi || @ wireless mini summit<br />
|-<br />
| 096 || [[User:Hondra| Ondrej Hudlicky]] || X || L || || <br />
|-<br />
| 097 || Petr Muller || X || XL || pmuller -at- redhat.com || <br />
|-<br />
| 098 || [[User:Rdieter|Rex Dieter]] || X || XL || || partial funding (hopefully) coming from kde<br />
|-<br />
| 099 || Sirko Kemter || || XL || sirko at radiotux.de || <br />
|-<br />
| 100 || [[User:Markmc|Mark McLoughlin]] || || M || || <br />
|-<br />
| 101 || [[User:Rjones|Richard Jones]] || || XL || || Red Hat is funding<br />
|-<br />
| 102 || [[User:Jjmcd|John J. McDonough]] || || XL || || Was on here a few weeks ago but disappeared. Not to be confused with [[User:Jpmcd]] #77<br />
|-<br />
| 103 || [[User:thoger|Tomas Hoger]] || || L || ||<br />
|-<br />
| 104 || [[User:mauelsha|Heinz Mauelshagen]] || || XL || heinzm@redhat.com || Red Hat is funding<br />
|-<br />
| 105 || [[User:dmaphy|Dominic Hopf]] || X || XL || ||<br />
|-<br />
| 106 || Eduard Benes || X || L || ebenes AT redhat PUNKT com ||<br />
|-<br />
| 107 || [[JoergSimon]] || || XXL || || Hope to make it for at least one Day!<br />
|-<br />
| 108 || [[User:mmalik|Milos Malik]] || X || L || mmalik AT redhat DOT com ||<br />
|-<br />
| 109 || [[User:th0br0|Andreas Osowski]] || X || M || th0br0 AT mkdir DOT name || Funding is arranged; I talked to Max<br />
|-<br />
| 110 || Heinrich Witt || || XXXL || hawitt@live.de || staying at berliner-family<br />
|-<br />
| 111 || Michael Münch || || M || micm -at- gmx.com ||<br />
|-<br />
| 112 || Helmut Schaa || || L || helmut.schaa -at- googlemail.com || @ wireless mini summit<br />
|-<br />
| 113 || [[User:kenda|Marcus Nitzschke]] || || L || ||<br />
|-<br />
| 114 || Clemens Hoffmann || || M || ||<br />
|-<br />
| 115 || Michal Ingeli || || M || mi@v3.sk || no LinuxTag; sleeping somewhere-nowhere<br />
|-<br />
| 116|| Michel Racic|| || L || mracic -ät- hsz-t.ch || bed n breakfast ;-)<br />
|-<br />
| 117|| [[ThomasSailer]] || || L || || about 30% chance I can attend a day. will only be able to decide shortly before<br />
|-<br />
| 118|| Guido Ledermann || || L || guido.ledermann at googlemail.com || <br />
|-<br />
| 119|| Ahmad Ali Tabassam || || M || ahmad-ali.tabassam at hs-owl.de || @ wireless mini summit <br />
|-<br />
| 120|| Jan Wildeboer || || ??? || ||<br />
|-<br />
| 121|| Reiner Luett || || XXL || diffusae at yahoo.se ||<br />
|-<br />
| 122|| Christopher Grebs|| || XXL || cg at webshox dot org || first FUDCon… let's see :-) ||<br />
|-<br />
| 123 || [[ZdenekPrikryl]] || X || L || zprikryl AT redhat DOT com ||<br />
|-<br />
| 124 || Jos Vos || || XL || jos@xos.nl ||<br />
|-<br />
| 125 || Angela Moschner|| || S || tdaria@gmail.com ||<br />
|-<br />
| 126 || Joel Granados || X || XL || jgranado at redhat dot com || Red Hat is funding <br />
|-<br />
| 127 || Michal Marciniszyn || || XL || mmarcini at redhat dot com || <br />
|-<br />
| 128 || Ben Levenson || || M || benl at redhat dot com || <br />
|-<br />
| 129 || Tom Coughlan || || L || coughlan at redhat dot com || <br />
|-<br />
| 130 || Nick Kossifidis || || M || mickflemm at gmail dot com || @ wireless mini summit <br />
|-<br />
| 131 || [[User:jkeating|Jesse Keating]] || x || XL || jkeating at redhat dot com || Giving barcamp and maybe hackfest sessions<br />
|-<br />
| 132 || Michael Koundourakis || || M || michael dot koundourakis at csr dot com || @ wireless mini summit <br />
|-<br />
| 133 || Tim Chick || || L || tim dot chick at csr dot com || @ wireless mini summit <br />
|-<br />
| 134 || Mikulas Patocka || || XL || mpatocka@redhat.com ||<br />
|-<br />
| 135 || [[User:chitlesh|Chitlesh Goorah]] || || M || ||<br />
|-<br />
| 136 || [[User:Stevetraylen|Steve Traylen]] || || XL || steve@traylen.net ||<br />
|- <br />
| 137 || [[User:Slankes|Sven Lankes]] || || XL || ||<br />
|-<br />
| 138 || [[User:gd|Guenther Deschner]] || || S || gdeschner at redhat com ||<br />
|-<br />
| Number || Name || Funding? || Shirt size? || Email address (if not on your wiki page) || Notes<br />
|}<br />
<br />
<br />
[[Category:Events]] [[Category:FUDCon]]</div>Gd