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 106 commits by 2 people in the last month.

Bazaar branches

Name Status Last Modified Last Commit
lp:putty
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 2020-02-28 20:48:52 UTC 4 hours ago
5743. Reject all low-order points in Montgo...

Author: Simon Tatham
Revision Date: 2020-02-28 20:48:52 UTC

Reject all low-order points in Montgomery key exchange.

This expands our previous check for the public value being zero, to
take in all the values that will _become_ zero after not many steps.

The actual check at run time is done using the new is_infinite query
method for Montgomery curve points. Test cases in cryptsuite.py cover
all the dangerous values I generated via all that fiddly quartic-
solving code.

(DJB's page http://cr.yp.to/ecdh.html#validate also lists these same
constants. But working them out again for myself makes me confident I
can do it again for other similar curves, such as Curve448.)

In particular, this makes us fully compliant with RFC 7748's demand to
check we didn't generate a trivial output key, which can happen if the
other end sends any of those low-order values.

I don't actually see why this is a vital check to perform for security
purposes, for the same reason that we didn't classify the bug
'diffie-hellman-range-check' as a vulnerability: I can't really see
what the other end's incentive might be to deliberately send one of
these nonsense values (and you can't do it by accident - none of these
values is a power of the canonical base point). It's not that a DH
participant couldn't possible want to secretly expose the session
traffic - but there are plenty of more subtle (and less subtle!) ways
to do it, so you don't really gain anything by forcing them to use one
of those instead. But the RFC says to check, so we check.

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