Re: [Savannah-hackers] submission of Peer Agent - savannah.nongnu.org

[Sylvain Beucler]

Richard,

Would you mind read the following thread:
* http://lists.gnu.org/archive/html/savannah-hackers/2004-10/msg00194.html
* http://lists.gnu.org/archive/html/savannah-hackers/2004-10/msg00203.html
* http://lists.gnu.org/archive/html/savannah-hackers/2004-10/msg00205.html
* (not archived, but included in the reply below)
* http://lists.gnu.org/archive/html/savannah-hackers/2004-10/msg00255.html
that ends with the following message?

It regards the Java policy at Savannah. The user, Robert Fischer,
argues that we should make an exception for Java as a proprietary
dependency, because he thinks the GNU project made an exception of the
same kind for Unix 20 years ago.

I pointed him to two of the articles in philosophy/ (the history of
the GNU project from "Open Sources", and "the Java Trap"), but he is
not convinced.

Maybe we need some additional documentation on that point. Could you
reply to Robert?

Currently, the thread is on savannah-hackers (public).


I will continue the technical discussion on sandbox environments once
this first issue is closed.

-- 
Sylvain


On Sat, Oct 09, 2004 at 07:48:44AM -0400, Robert Fischer, PhD wrote:
>   Here, you are not developing a free sandbox environnement; you are
>   using it. This will not help to get rid of the proprietary dependency.
>   It is not acceptable to say "there is no free software for that task,
>   so I use proprietary software".
> 
> Again, I still believe that past FSF practice was otherwise.  Emacs was
> developed before GCC, for example.  The Emacs project was not stalled
> just because there was no GCC.  Rather, the EXPECTION of a GCC led
> people to build free software in C that would EVENTUALLY be able to
> compile with GCC.  Once GCC came out and matured, support for other
> compilers was eventually dropped.
> 
> The difference between Qt and GCC is not so cut-and-dried.  In the case
> of GCC, the FSF practiced the embrace-and-extend model.  C was already
> popular, so rather than inventing a new language, the GNU Project built
> to a pre-existing standard.  At that point, GNU extensions were added to
> GCC (although there's always been an --ansi mode).  A brilliant
> competetive strategy later adopted by Microsoft.
> 
> The FSF could have done the same thing with Qt: write a free replacement
> for Qt, then take control of the further development of that standard by
> extending it.  Then we would just have Qt and GNU Qt, rather than
> completely different widget sets Qt and GTK.  I'm not saying that anyone
> SHOULD have taken this approach --- just that it would have been
> possible.
> 
> It seems then, that the difference between Qt and C was a difference of
> INTENTION on the part of the free software community.  Since a free C
> Compiler was INTENDED, it was OK to write C programs.  However, there
> was no INTENTION to write a free Qt, so it was not OK to write Qt
> programs.
> 
> My biggest worry here is that there has been, for the last 8 years, no
> INTENTION to write any reasonable free Java replacement.  Had serious
> resources been committed to that project --- as was done with GCC --- we
> would now have a top-of-the-line Java system, and could be succeeding
> handily at the "embrace and extend" game with Sun.  Instead, we've just
> sat around and griped that Java is not free.
> 
> Sandboxable bytecode systems are important today because they help solve
> important problems --- the execution of untrusted code --- that are not
> solved any other commonly available, mature technology.  Unfortunately,
> I do not believe most of the Free Software community has yet recognized
> this need.  And it is something we MUST recognize and commit to at some
> point in a serious way, if we do not wish to end up playing a very
> difficult (if not legally impossible, thanks to the DMCA) game of
> catch-up with Palladium.
> 
> > Independently of the above, are you sure the problem comes from GCJ?
> > It seems to me that the security manager would be located in GIJ, with
> > checks in the Classpath library.
> 
> > Did you contact the people working on free java software (and as you
> > suggested, free .net software)? The fact they do not mention any
> > sandbox does not mean there is not any under work. For example,
> > http://sv.gnu.org/p/gcjwebplugin/ . Can do that?
> 
> Security is different from functionality.  If functionality has been
> added to a piece of software --- Swing, for example --- I can run it,
> verify the functionality is there, and then use it.
> 
> Proving security is a LOT harder.  Because you must prove the
> functionality is NOT there --- functionality for malicious code to do
> anything "bad" to your system.
> 
> In the Java design, security relies on the following "security stack":
>  1. Language design
>  2. Bytecode verifier
>  3. Security Manager
>  4. Proper use in applications
> 
> I have read repeatedly that Kaffe does not have a bytecode verifier. 
> And never have I seen a bytecode verifier for GCJ either.  Therefore, a
> crucial link in running untrusted classfiles securely with GCJ is
> missing.  However, with a security manager in place, I suppose that with
> a security manager in place, one COULD trust GCJ to compile and run
> untrusted java SOURCE code.
> 
> Maybe a way to do "bytecode verification" in GCJ would be to de-compile
> a classfile into Java, then compile with GCJ.  Bytecode verification
> protects against bytecode that is not legal Java, and this procedure
> would (in theory) have the same effect.
> 
> > Some various remarks after I reread your project description:
> > - BCEL is free software, it is just GPL-incompatible (Apache License)
> 
> Yes, that is true.  Actually, the "replacement" for BCEL is some
> specialized, yucky hand-hacked code that I wrote originally.  Then a
> student decided it would be "so much better" if we use BCEL.  Sigh... 
> At least going back to the original won't be so hard.
> 
> > - Using Swing is a problem similar to the sandbox one. Still, you
> >   can use AWT, SWT or the Gtk Java bindings.
> 
> Yes, but Swing is rapidly evolving in CLASSPATH, is it not?
> 
>   Did you contact the people working on free java software (and as you
>   suggested, free .net software)? The fact they do not mention any
>   sandbox does not mean there is not any under work. For example,
>   http://sv.gnu.org/p/gcjwebplugin/ . Can do that?
> 
> One of the Savannah requirements is that the software work AT LEAST as
> well on a free platform as on a non-free platform.  I can only make that
> judgment based on RELEASED versions of the platform.  Furthermore, a
> search of the newsgroups and a look at the "future directions" pages
> give significant insight into the current plans for the project.
> 
> The free .NET software (Mono, actually closely associated with GNOME),
> as far as I can tell, DOES have an effective security manager.  The
> ultimate security of this will have to be verified with time.  Until we
> believe it's secure, I cannot realistically make the claim that my
> software works at least as well on Mono as on .NET.
> 
> Furthermore, Mono is very new.  When I started my project, it was still
> vaporware / betaware.  Again, I cannot rely on vaporware.  So at that
> point, Java (which runs cross-platform and has available development
> tools from multiple vendors) was a better choice than .NET (which was
> heavily tied to Windows).
> 
> The emergence of Mono will have interesting consequences.  Miguel de
> Icaza took a lot of flak for playing embrace and extend with Microsoft. 
> But at this point, Mono/C# is free and Java is not.  And Mono is
> probably going to be embedded deep within much of Gnome in the future. 
> Eventually, people will probably come around and use it.  That will
> introduce fundamental compatibilities between the free software and
> Windows worlds: as long as all the relevant APIs are implemented in
> Mono, Mono can run .NET Windows binaries UNCHANGED.  We could be left
> with the Free Software community and Microsoft supporting one standard
> (.NET) and Sun left out in the cold, for Java to eventually die or be
> subsumed by Mono.
> 
> If I were to start the project now, I might choose Mono instead.  I
> might translate the past code to C#/Mono as well.