PuTTY hosts its code at svn://svn.tartarus.org/sgt/putty.

You can learn more at the project's web page.

Launchpad imports the master branch and you can create branches from it.

You can browse the source code for the development focus branch or get a copy of the branch using the command:
bzr branch lp:putty

PuTTY has 2 active branches owned by 1 team. There were 0 commits in the last month.

Bazaar branches

Name Status Last Modified Last Commit
Series: trunk
1 Development 2014-10-21 11:33:33 UTC 2014-10-21
3757. Cross-reference the description of wi...

Author: jacob
Revision Date: 2014-10-21 11:33:33 UTC

Cross-reference the description of winadj@putty.projects.tartarus.org
to its bug-compatibility mode.

lp:~vcs-imports/putty/master 1 Development 2018-07-10 20:27:43 UTC 2018-07-10
4821. Move password-packet padding into the...

Author: Simon Tatham
Revision Date: 2018-07-10 20:27:43 UTC

Move password-packet padding into the BPP module.

Now when we construct a packet containing sensitive data, we just set
a field saying '... and make it take up at least this much space, to
disguise its true size', and nothing in the rest of the system worries
about that flag until ssh2bpp.c acts on it.

Also, I've changed the strategy for doing the padding. Previously, we
were following the real packet with an SSH_MSG_IGNORE to make up the
size. But that was only a partial defence: it works OK against passive
traffic analysis, but an attacker proxying the TCP stream and
dribbling it out one byte at a time could still have found out the
size of the real packet by noting when the dribbled data provoked a
response. Now I put the SSH_MSG_IGNORE _first_, which should defeat
that attack.

But that in turn doesn't work when we're doing compression, because we
can't predict the compressed sizes accurately enough to make that
strategy sensible. Fortunately, compression provides an alternative
strategy anyway: if we've got zlib turned on when we send one of these
sensitive packets, then we can pad out the compressed zlib data as
much as we like by adding empty RFC1951 blocks (effectively chaining
ZLIB_PARTIAL_FLUSHes). So both strategies should now be dribble-proof.

12 of 2 results
You can't create new branches for PuTTY.