2009 Google Summer of Code

[Damien Miller]

Hi,

Over the last two weeks I have received a large number of emails
regarding OpenSSH's participation in the 2009 Google Summer of Code
program.

This email should answer the questions that you collectively asked.
Please forgive this bulk reply - there are simply too many of you to
reply to individually. If I have failed to answer your question, please
feel free to email me again.

If you haven't already done so, please read the GSoC FAQ:
http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs

Here are the answers to your questions:

1. Applications

Quite a few of you sent applications to participate to me directly. I'm
not able to act on these unless they are made though the application
tool on the GSoC website http://socghop.appspot.com/ so please make your
application there.

2. Decision criteria

When assessing the applications the things that I will be looking for
will be:

1) A demonstration of understanding of the problem/idea that the student
   has chosen.

2) Evidence that they have the necessary skills to take it on. This may
   take the form of prior free software contributions, patch submissions
   or code samples that I can look at. Academic experience alone is
   likely to be insufficient.

3) A good schedule of tasks to implement the idea and a realistic
   time-line for completing them. We *strongly* favour decomposition of
   work into smaller units that can be reviewed and completed
   independently and it is not a coincidence that the ideas that we have
   listed can be broken down in this way.

   Students who go a little beyond the stated requirements (e.g. by
   including "stretch goals") while still remaining realistic in their
   proposals will be preferred.

3. Start date

The official GSoC start date for contributors is May 23, but some of you
have asked about starting early. Students starting the actual work early
is OK, but I think there is some advantage of familiarising oneself with
the project, its source code, practices and culture first. The GSoC
includes two months of "Community Bonding Period" to facilitate this,
but if the student feels that they are ready sooner then that is OK.

4. Level of commitment

Some of you asked about how of your time you would have to dedicate
to work on GSoC projects. This is completely up to you! You should
decide your own level of commitment and base your proposals around
that. Obviously, students with more ambitious proposals will have some
advantage (so long as they are realistic), but we certainly don't want
to burn you out and sour your experience with free software development.

5. Assessment

This being the first time OpenSSH has participated in GSoC, I'm ignorant
of what criteria the program will ask us to use when evaluating
students' work. From my perspective, the main criteria will be "how much
have they improved OpenSSH?" Bear in mind that improving OpenSSH means
getting code completed, reviewed and committed to our CVS repository

6. Specific projects

Many of the questions were about the specific ideas that we had listed
on http://www.openssh.com/gsoc.html so here is some more detail on each:

6.1 Renovate sftp

The motivation for this idea is to make sftp(1) a compelling replacement
for scp(1). scp(1) has a very easy to use command-line interface,
supports recursive copies ("scp -r") and is quite fast - it does not
need a server round-trip for each file that it copies. Unfortunately
scp(1) is unmaintainable - its protocol practically requires shell
access and has no backwards compatibility or extensibility support.

So this project would be adding these missing features to sftp(1) and
exposing them via a commandline that is as compatible with scp(1)'s as
possible. Beyond this baseline, there are a number of other things that
may be done to improve sftp(1):

- Implement tab-completion in interactive mode. Ben Lindstrom has written
  a patch to implement this, and it only needs a tiny amount of work to
  get it committed.

- Improve the interactive interface. Right now, things like
  "get file1 file2 file3" don't work, or don't do what one might normally
  expect.
  
  Also, the sftp client currently requires read access to every
  component of the patch in which it is operating (i.e. traverse-only
  directories break it) - there is no protocol-level reason why this needs
  to be the case so this could be fixed fairly easily too.

6.2 Improved testing infrastructure

There weren't too many questions on this. I hope the description given at
http://www.openssh.com/gsoc.html#testing was enough explanation to get
someone started. 

6.3 Performance improvements

There are three main metrics by which OpenSSH's performance may be measured
when performing some operation such as transferring a directory of files,
connect to a server or moving a fixed quantity of data:

- How long does it take?
- How much CPU time does it take?
- How much memory does it take?

Environmental considerations can affect these, especially network latency.
Over the last couple of releases, we have worked to improve transfer speed
on high bandwidth*delay links as well as general CPU performance, but
there is certainly more that can be done especially in the area of memory
consumption.

The first step would be to develop some good benchmarks that measure
various aspects of OpenSSH's performance. Ideally, these should be able
to be run alongside the standard suite of regression tests so we can 
ensure that we do not regress performance-wise in the future.

>From there, the student would need to identify and fix performance
bottlenecks or waste. 

There is an external project
http://www.psc.edu/networking/projects/hpn-ssh/ that has conducted quite
a bit of work on making OpenSSH faster which a student could use as a
resource.

6.4 Other projects

There were a couple of people who suggested writing GUI frontends to
parts of OpenSSH. This might be a good idea, but its not something
that we would accept as a GSoC project - we aren't likely to ever ship
GUI tools in OpenSSH and I personally lack the necessary experience to
properly assess contributions in this area.

----

Thank you all very much for your interest, and please feel welcome to
send any additional questions to myself or to the public OpenSSH mailing
list: https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Regards,
Damien Miller