Balazs Scheidler <[EMAIL PROTECTED]> writes: > I see four possible solutions: > > 1) pass ssh_connection to the signers as a parameter, which is bad, since > things in abstract_crypto.h should not depend on connection.h I agree that would be really ugly. > 2) pass a bool parameter (old_signature), which is true when old > signatures should be generated, not a good one either. > 3) use a global variable, which is the worst > 4) create another signer/verifier descendant (dsa_old_signer, > dsa_old_verifier), which would generate the old-style signatures, this > would be good, but signer is initialized when the hostkey is read (e.g. > no version string is known), and as the connection is opened this > object has to be replaced by an instance of dsa_old_signer _iff_ ssh2 > is version 2.0.11 or below and the selected keyexchange method is > diffie-hellman. > what is your suggestion? I would go for #4, so I begin implementing it. Here are some random thougts on the subject... My first reaction is that handling it as a distinct signature algorithm is probably the right way. The "version string not known when host key is read" applies only to lshd, right? Perhaps you could simply initialize two different signer objects. I don't really know how to fit that into the keyexchange mechanism, though. Another alternative is to keep an extra structure for "miscellaneous options", i.e. configuration stuff that doesn't fit anywhere else. There should probably be one global structure, and per connection structures that can shadow it. Then we could call some callback function when the version string is read; which could modify the connection options in anyway it likes. A third alternative is what you suggested in your last message: to have the keyexchange mechanism do some postprocessing of the signature created by the ordinary dsa-signer object. If this can be done without to much trouble, it may be a very reasonable way. Or have the keyexchange mechanism patch "ssh-dss"->"ssh-dss-kludge", and use this when selecting signer object. There ought to be support for some alist signature-algorithm -> signer object anyway. /Niels
