X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fmono-hacking-roadmap.html;h=134a1d425412fd51c2b2754a5c7beb949543d754;hb=4347c57e9783cf9348af2e0ec773024ab6d9b9fc;hp=30e7645e758558a1c5e71739bc38661ea5bed912;hpb=22f7c0029961b0dedbbed3ebaa6d12d0ac5c4419;p=mono.git

diff --git a/web/mono-hacking-roadmap.html b/web/mono-hacking-roadmap.html
index 30e7645e758..134a1d42541 100644
--- a/web/mono-hacking-roadmap.html
+++ b/web/mono-hacking-roadmap.html
@@ -129,9 +129,50 @@ vertical-align: top;
 		<li>ECMA profile: We will like take care of this one
 		at Novell.
 
-		<li>Assembly signing: I do not know what is the state
-		of this feature currently in Mono, maybe Sebastien and
-		Zoltan could give us an update here.
+		<li>Assembly signing: There are two ways to sign 
+		assemblies.<br>
+
+			<b>StrongNames</b> - It is possible to sign
+			and verify strongname signatures using the 
+			sn.exe security tool. This same tool can also
+			create the required key pairs to sign the 
+			assemblies. What we are lacking:
+			<ul>
+				<li>The runtime doesn't check
+				strongname signatures (if present) 
+				when loading an assembly outside the
+				GAC;
+				<li>sn.exe cannot be used to sign, 
+				nor verify, an assembly that contains
+				the "ECMA public key";
+				<li>sn.exe doesn't support all options
+				to turn on/off runtime verification
+				for some assemblies;
+				<li>StrongNameIdentityPermission 
+				support isn't complete as it depends
+				on CAS.
+			</ul>
+
+			<b>Authenticode</b> - It is possible today
+			to sign assemblies (in fact any PE file) with
+			an Authenticode(r) compatible signature (with
+			or without a timestamp) using the security 
+			tools cert2spc.exe and signcode.exe. We also
+			have support to test this using the tools 
+			makecert.exe, chktrust.exe and setreg.exe.
+			What we are lacking:
+			<ul>
+				<li>Currently our X.509 certificate
+				chaining is very limited and we do 
+				not support certificate revocation 
+				in anyway;
+				<li>Not every options are implemented
+				in all tools (and some do not really
+				apply to Mono);
+				<li>PublisherIdentityPermission 
+				support isn't complete as it depends
+				on CAS.
+			</ul>
 
 		<li>ASP.NET caching: Non-existant at this point, this
 		needs to be implemented. 
@@ -148,9 +189,17 @@ vertical-align: top;
 		areas missing.
 	</ul>
 
-	<p>The team at Novell can probably take care of most of these
-	things (help is always welcomed, of course), letting folks in
-	the open source world working on the more fun components. 
+	<p>The team at Novell will focus on these areas.  We of course
+	welcomes the contribution of the rest of the Mono team and
+	encourage the developers to focus on 1.0, to have a solid
+	release, and a solid foundation that can lead to 1.2
+
+	<p>We will use Bugzilla milestones to track these issues. 
+
+<h3>Synchronized releases</h3>
+
+	<p>It would be great if we can ship Mono 1.0 with Gtk# 1.0 and
+	a preview of Monodoc with the early documentation.  
 	
 <h3>Alpha components.</h3>
 
@@ -219,7 +268,7 @@ vertical-align: top;
 	
 <h3>Avalon plans</h3>
 
-	<p>On the surface Avalaon seems like it uses something like
+	<p>On the surface Avalon seems like it uses something like
 	GdiPlus/Cairo for rendering.  That was my initial feeling, but
 	it turns out that they had to rewrite everything to have a
 	performing rendering engine, and implement some very advanced
@@ -247,7 +296,7 @@ vertical-align: top;
 <h3>Indigo Plans</h3>
 
 	<p>Indigo is still an early product (<a
-	href="http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx?pull=/library/en-us/dnlong/html/indigofaq1.asp">FAQ</a>,
+	href="http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx?pull=/library/en-us/dnlong/html/indigofaq1.asp">FAQ</a>),
 	but it could benefit from continued development of our WSE1
 	and WSE2 components, later to bring some of the code to it.