Re: [Twisted-Python] continuous integration update

[Glyph Lefkowitz]

> On Dec 2, 2016, at 2:18 PM, Glyph Lefkowitz  wrote:
> 
> Hi all,
> 
> On Github, the process was supposed to be that we push any 3rd-party 
> contributor branches to the buildbots before doing a final merge.  However, 
> we (myself included, I think) have been landing PRs without doing that first.
> 
> In order to ensure that the process is followed, I've added a representative 
> sample of buildbot status checks - specifically, buildbot/osx10.10-py2.7, 
> buildbot/freebsd10-py3.5, and buildbot/freebsd10-py2.7 to the required list.

Oops. Apparently the FreeBSD ones aren't supported builds, and therefore don't 
run on every PR, so they were jamming things up.  I've reduced it to just the 
OS X builder.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Spurious commit/ticket links

[Glyph Lefkowitz]

> On Dec 2, 2016, at 4:49 PM, Jean-Paul Calderone  
> wrote:
> 
> I deployed this to production.  I don't see a good way to test it without 
> screwing around with twisted trunk ... so don't plan to.  I'll keep an eye on 
> real merges folks are working on and see if it's behaving as desired.

Thanks, JP!

Would you mind updating 
https://twistedmatrix.com/trac/wiki/ReviewProcess#Revertingachange and 
https://twistedmatrix.com/trac/wiki/ReviewProcess#Authors:Howtomergethechangetotrunk
 to reflect the new syntax that should be used on future merges?

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Spurious commit/ticket links

[Jean-Paul Calderone]

I deployed this to production.  I don't see a good way to test it without
screwing around with twisted trunk ... so don't plan to.  I'll keep an eye
on real merges folks are working on and see if it's behaving as desired.

On Thu, Dec 1, 2016 at 8:50 PM, Jean-Paul Calderone <
exar...@twistedmatrix.com> wrote:

> On Thu, Dec 1, 2016 at 3:33 PM, Glyph Lefkowitz 
> wrote:
>
>>
>>
>> Please be vocal about any roadblocks you hit.  The ops situation has
>> improved a ton since the last time you looked, but (accordingly) it's also
>> changed almost completely.
>>
>> Good luck - and hopefully you'll need a lot less of it than previously
>> ;-).
>>
>>
> Here's a new plugin that has the new behavior, maybe:
> https://github.com/twisted-infra/twisted-trac-plugins/pull/4
> thijs did a review so maybe it's all set to merge.
> There's also a config change: https://github.com/
> twisted-infra/braid/pull/226
>
> I had intended to test it with the local development environment but it
> looks like it requires downloading gigs of data for vagrant boxes and to
> upgrade a super-old ubuntu image.
> Maybe someone else could do that step.
>
> If not, maybe I'll test it on the production machine in a couple days. :)
>
> Jean-Paul
>
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Craig Rodrigues]

Glyph,

I took your fix, and added some fixes of my own for __repr__() printing of
EC keys in this branch:

https://github.com/twisted/twisted/pull/615


If I run the tests, I get a new failure:


trial twisted.conch.test.test_keys.KeyTests.test_fromBlobECDSA

Traceback (most recent call last):
  File "/Users/crodrigues/twisted_15/src/twisted/conch/test/test_keys.py",
line 776, in test_fromBlobECDSA
eckey = keys.Key.fromString(ecblob)
  File "/Users/crodrigues/twisted_15/src/twisted/conch/ssh/keys.py", line
197, in fromString
return method(data)
  File "/Users/crodrigues/twisted_15/src/twisted/conch/ssh/keys.py", line
253, in _fromString_BLOB
default_backend()))
  File
"/Users/crodrigues/venv-3.6/lib/python3.6/site-packages/cryptography/hazmat/primitives/serialization.py",
line 69, in load_ssh_public_key
return loader(key_type, rest, backend)
  File
"/Users/crodrigues/venv-3.6/lib/python3.6/site-packages/cryptography/hazmat/primitives/serialization.py",
line 103, in _load_ssh_ecdsa_public_key
'Key header and key body contain different key type values.'

builtins.ValueError: Key header and key body contain different key type
values.


Also, if I try to access my machine with:
conch 192.168.1.2

I see that in the matchesKey() function on this line:
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/client/knownhosts.py#L106

self.publicKey is an EC key, while keyObject is an RSA key.

Therefore this function always fails, and I cannot log into the box.

Any ideas?

Thanks.
--
Craig
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] continuous integration update

[Glyph Lefkowitz]

Hi all,

On Github, the process was supposed to be that we push any 3rd-party 
contributor branches to the buildbots before doing a final merge.  However, we 
(myself included, I think) have been landing PRs without doing that first.

In order to ensure that the process is followed, I've added a representative 
sample of buildbot status checks - specifically, buildbot/osx10.10-py2.7, 
buildbot/freebsd10-py3.5, and buildbot/freebsd10-py2.7 to the required list.

Additionally, I think I'd like to take our Mac builds off of Travis.  They're 
still in the allow_fail section, so they haven't been blocking merges, but a 
Travis build can't complete (and therefore register as "succeded") without 
them.  Given the repeated OS X related incidents on Travis (see here 
https://www.traviscistatus.com/incidents/nq0sf0srvx8s and here 
https://www.traviscistatus.com/incidents/3d430hxd59ft here 
https://www.traviscistatus.com/incidents/06xg686x7wgw and here 
https://www.traviscistatus.com/incidents/w82t22dlpntr and here 
https://www.traviscistatus.com/incidents/j7ttlsnbkf33 if you haven't been 
personally affected) the OS X builds have been responsible for something like 
90% of our build times and have prevented me from making a lot of progress this 
week.  I've submitted a PR for this at 
https://github.com/twisted/twisted/pull/614 which hopefully someone can review 
and merge if they agree.

Thanks,

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Craig Rodrigues]

On Fri, Dec 2, 2016 at 9:18 AM, Craig Rodrigues 
wrote:

>
> Traceback (most recent call last):
>
>
>   File "", line 1, in 
>   File "/Users/crodrigues/twisted8/src/twisted/conch/ssh/keys.py", line
> 787, in __repr__
> self._keyObject.key_size)]
>
> AttributeError: '_EllipticCurvePublicKey' object has no attribute
> 'key_size'
>
>
This seems to be the problem.

On this line:
https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/ssh/keys.py#L782
the __repr__() function wants to call the key_size() method.

This seems to exist for DSA and RSA keys:
https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/dsa.py#L232
https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/rsa.py#L482

However for EC keys, I do not see a 'key_size' attribute:
https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/backends/openssl/ec.py#L256

When trying to compare the known host key, the code tries to do a
__repr__() and it fails,
so this doesn't seem to work with EC keys.

--
Craig
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Craig Rodrigues]

On Fri, Dec 2, 2016 at 1:23 AM, Glyph Lefkowitz 
wrote:

>
>
> Investigating further, I think I've figured it out.  Here's a patch that
> fixes the problem:
>
> diff --git a/src/twisted/conch/ssh/keys.py b/src/twisted/conch/ssh/keys.py
> index d47db7f..570f524 100644
> --- a/src/twisted/conch/ssh/keys.py
> +++ b/src/twisted/conch/ssh/keys.py
> @@ -247,8 +247,10 @@ class Key(object):
>  ).public_key(default_backend())
>  )
>  elif keyType in [b'ecdsa-sha2-' + curve for curve in
> list(_curveTable.keys())]:
> -x, y, rest = common.getMP(rest, 2)
> -return cls._fromECComponents(x=x, y=y, curve=keyType)
> +return cls(load_ssh_public_key(
> +keyType + b' ' + base64.encodestring(blob),
> +default_backend())
> +)
>  else:
>  raise BadKeyError('unknown blob type: %s' % (keyType,))
>
>
> I suspect, but do not fully understand, that the problem here is point
> compression.  Key._fromString_BLOB naively just does getMP(blob, 2) and
> expects that the x,y will be the EC point.  However, to quote
> https://tools.ietf.org/html/rfc5656#section-3.1, "point compression MAY
> be used".  I don't know exactly how point compression works, but I do
> understand that it means you do funky stuff with the Y value.  I do not
> believe that EllipticCurvePrivateNumbers understands said funky stuff.
>
> A specific ECC integration test with ssh-keygen from OpenSSH and
> twisted.conch.client.knownhosts.KnownHostsFile would have spotted this
> specific manifestation of the issue.  However, another underlying bug is
> that KnownHostsFile _should_ ignore lines that it can't parse.  And,
> there's another potential manifestation of the issue where loading from an
> actual key blob might not work; arguably the problem here is that
> KnownHostsFile made the questionable decision to do its own base64-decoding
> and pass the blob straight to the key rather than just pass the portion of
> the line after the hostname and load it as an openssh-format key directly.
>
>
Yes, you are on the right track.  As the known_hosts file is parsed line by
line,
if an exception is thrown during parsing, then any valid keys further in
the file are ignored,
and you get the "bad host key" error.

I tried your patch, and while I don't get the same error, the patch doesn't
solve the problem for me.

I did some more debugging, and when I tried to put some print statements in
the code to
figure out what is going on, I found these errors:

Traceback (most recent call last):


  File "", line 1, in 
  File "/Users/crodrigues/twisted8/src/twisted/conch/ssh/keys.py", line
787, in __repr__
self._keyObject.key_size)]

AttributeError: '_EllipticCurvePublicKey' object has no attribute
'key_size'


and also this:

  File "/Users/crodrigues/twisted8/src/twisted/conch/client/knownhosts.py",
line 107, in matchesKey
print("SELF.PUBLICKEY ", self.publickey)
AttributeError: 'PlainEntry' object has no attribute 'publickey'

--
Craig
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Glyph Lefkowitz]

> On Dec 2, 2016, at 12:37 AM, Glyph Lefkowitz  wrote:
> 
> 
>> On Dec 2, 2016, at 12:27 AM, Glyph Lefkowitz > > wrote:
>> 
>> 
>>> On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz >> > wrote:
>>> 
>>> 
 On Dec 1, 2016, at 7:01 PM, Mark Williams > wrote:
 
 On Thu, Dec 01, 2016 at 05:11:37PM -0800, Craig Rodrigues wrote:
> Hi,
> 
> I filed this bug:
> https://twistedmatrix.com/trac/ticket/8931 
> 
> 
> At least for me, conch fails to parse a host key created by OpenSSH
> in ~/.ssh/known_hosts
> which is of type ecdsa-sha2-nistp256.
> 
> Anyone have an idea as to how to fix this?
> 
 
 As usual you've found a fantastically interesting issue.
 
 This is conch, the client, right?  I'm guessing so because
 ~/.ssh/known_hosts contains the servers the ssh client trusts.
 (Specifically, among other things it contains a hostname and that
 host's sshd server's public key fingerprint).
 
 If it is conch, the-client, then deleting the offending entry from
 ~/.ssh/known_hosts and getting a new one makes sense.  That's because
 sshd usually generates a couple of different keys in case clients
 don't support the latest and greatest technology.
 
 I think deleting the entry in ~/.ssh/known_hosts allows conch to ask
 the server for a different key that it *can* understand.  You should
 be able to find out which server key conch negotiated by doing thing
 following after deleting the offending ~/.ssh/known_hosts entry:
 
 ()
 $ ssh-keygen -H -F  | awk '{ print $NF }'
 dGhpcyBpcyB2ZXJ5IHZlcnkgdmVyeSB2ZXJ5IHZlcnkgbG9uZyBob3N0IGtleQ==
 
 Then on the OS X server, grep for that in /etc/ssh/*.pub
 
 I bet the key negotiated by conch is not an ECDSA key but rather an
 RSA key.  If this is all the case, then I think you've found a key
 that LibreSSL supports but your client's libssl (which conch calls
 into via cryptography) does not.  What version of libssl do you have?
 
 If any of this is helpful or relevant I'll ask more questions in the
 ticket.
>>> 
>>> I think there might be a regression in 16.6.0.
>>> 
>>> For every version up to 16.6.0, I can do 'conch twistedmatrix.com 
>>> ' in a shell and it works fine.
>>> 
>>> On 16.6.0, I get:
>>> 
>>> Connection to twistedmatrix.com  closed.
>>> conch: exiting with error [Failure instance: Traceback (failure with no 
>>> frames): : ('bad host key', 9)
>>> ]
>>> 
>>> instead.
>>> 
>>> Worth noting: the keys I have for twistedmatrix.com 
>>>  are RSA keys.
>>> 
>>> What did we add recently that changes key parsing?
>> 
>> The offending commit is 8164d89104a453947215b9296e8b406f15e63252.  Clearly 
>> something went wrong when introducing ECDSA parsing.
> 
> The problem is not quite as bad as breaking RSA parsing, at least; the issue 
> is that my known_hosts file includes an ecdsa-sha2-nistp256 entry that 
> _precedes_ my ssh-rsa entry.  So the problem is that parsing one of those 
> entries raises an exception which propagates.  From a superficial 
> investigation, it would appear that _all_ ecdsa keys cause this failure, 
> though.

Investigating further, I think I've figured it out.  Here's a patch that fixes 
the problem:

diff --git a/src/twisted/conch/ssh/keys.py b/src/twisted/conch/ssh/keys.py
index d47db7f..570f524 100644
--- a/src/twisted/conch/ssh/keys.py
+++ b/src/twisted/conch/ssh/keys.py
@@ -247,8 +247,10 @@ class Key(object):
 ).public_key(default_backend())
 )
 elif keyType in [b'ecdsa-sha2-' + curve for curve in 
list(_curveTable.keys())]:
-x, y, rest = common.getMP(rest, 2)
-return cls._fromECComponents(x=x, y=y, curve=keyType)
+return cls(load_ssh_public_key(
+keyType + b' ' + base64.encodestring(blob),
+default_backend())
+)
 else:
 raise BadKeyError('unknown blob type: %s' % (keyType,))
 
I suspect, but do not fully understand, that the problem here is point 
compression.  Key._fromString_BLOB naively just does getMP(blob, 2) and expects 
that the x,y will be the EC point.  However, to quote 
https://tools.ietf.org/html/rfc5656#section-3.1, "point compression MAY be 
used".  I don't know exactly how point compression works, but I do understand 
that it means you do funky stuff with the Y value.  I do not believe that 
EllipticCurvePrivateNumbers understands said funky stuff.

A specific ECC integration test with ssh-keygen from OpenSSH and 
twisted.conch.client.knownhosts.KnownHostsFile would have spotted this specific 

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Glyph Lefkowitz]

> On Dec 2, 2016, at 12:27 AM, Glyph Lefkowitz  wrote:
> 
> 
>> On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz > > wrote:
>> 
>> 
>>> On Dec 1, 2016, at 7:01 PM, Mark Williams >> > wrote:
>>> 
>>> On Thu, Dec 01, 2016 at 05:11:37PM -0800, Craig Rodrigues wrote:
 Hi,
 
 I filed this bug:
 https://twistedmatrix.com/trac/ticket/8931 
 
 
 At least for me, conch fails to parse a host key created by OpenSSH
 in ~/.ssh/known_hosts
 which is of type ecdsa-sha2-nistp256.
 
 Anyone have an idea as to how to fix this?
 
>>> 
>>> As usual you've found a fantastically interesting issue.
>>> 
>>> This is conch, the client, right?  I'm guessing so because
>>> ~/.ssh/known_hosts contains the servers the ssh client trusts.
>>> (Specifically, among other things it contains a hostname and that
>>> host's sshd server's public key fingerprint).
>>> 
>>> If it is conch, the-client, then deleting the offending entry from
>>> ~/.ssh/known_hosts and getting a new one makes sense.  That's because
>>> sshd usually generates a couple of different keys in case clients
>>> don't support the latest and greatest technology.
>>> 
>>> I think deleting the entry in ~/.ssh/known_hosts allows conch to ask
>>> the server for a different key that it *can* understand.  You should
>>> be able to find out which server key conch negotiated by doing thing
>>> following after deleting the offending ~/.ssh/known_hosts entry:
>>> 
>>> ()
>>> $ ssh-keygen -H -F  | awk '{ print $NF }'
>>> dGhpcyBpcyB2ZXJ5IHZlcnkgdmVyeSB2ZXJ5IHZlcnkgbG9uZyBob3N0IGtleQ==
>>> 
>>> Then on the OS X server, grep for that in /etc/ssh/*.pub
>>> 
>>> I bet the key negotiated by conch is not an ECDSA key but rather an
>>> RSA key.  If this is all the case, then I think you've found a key
>>> that LibreSSL supports but your client's libssl (which conch calls
>>> into via cryptography) does not.  What version of libssl do you have?
>>> 
>>> If any of this is helpful or relevant I'll ask more questions in the
>>> ticket.
>> 
>> I think there might be a regression in 16.6.0.
>> 
>> For every version up to 16.6.0, I can do 'conch twistedmatrix.com 
>> ' in a shell and it works fine.
>> 
>> On 16.6.0, I get:
>> 
>> Connection to twistedmatrix.com  closed.
>> conch: exiting with error [Failure instance: Traceback (failure with no 
>> frames): : ('bad host key', 9)
>> ]
>> 
>> instead.
>> 
>> Worth noting: the keys I have for twistedmatrix.com 
>>  are RSA keys.
>> 
>> What did we add recently that changes key parsing?
> 
> The offending commit is 8164d89104a453947215b9296e8b406f15e63252.  Clearly 
> something went wrong when introducing ECDSA parsing.

The problem is not quite as bad as breaking RSA parsing, at least; the issue is 
that my known_hosts file includes an ecdsa-sha2-nistp256 entry that _precedes_ 
my ssh-rsa entry.  So the problem is that parsing one of those entries raises 
an exception which propagates.  From a superficial investigation, it would 
appear that _all_ ecdsa keys cause this failure, though.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Glyph Lefkowitz]

> On Dec 2, 2016, at 12:19 AM, Glyph Lefkowitz  wrote:
> 
> 
>> On Dec 1, 2016, at 7:01 PM, Mark Williams > > wrote:
>> 
>> On Thu, Dec 01, 2016 at 05:11:37PM -0800, Craig Rodrigues wrote:
>>> Hi,
>>> 
>>> I filed this bug:
>>> https://twistedmatrix.com/trac/ticket/8931 
>>> 
>>> 
>>> At least for me, conch fails to parse a host key created by OpenSSH
>>> in ~/.ssh/known_hosts
>>> which is of type ecdsa-sha2-nistp256.
>>> 
>>> Anyone have an idea as to how to fix this?
>>> 
>> 
>> As usual you've found a fantastically interesting issue.
>> 
>> This is conch, the client, right?  I'm guessing so because
>> ~/.ssh/known_hosts contains the servers the ssh client trusts.
>> (Specifically, among other things it contains a hostname and that
>> host's sshd server's public key fingerprint).
>> 
>> If it is conch, the-client, then deleting the offending entry from
>> ~/.ssh/known_hosts and getting a new one makes sense.  That's because
>> sshd usually generates a couple of different keys in case clients
>> don't support the latest and greatest technology.
>> 
>> I think deleting the entry in ~/.ssh/known_hosts allows conch to ask
>> the server for a different key that it *can* understand.  You should
>> be able to find out which server key conch negotiated by doing thing
>> following after deleting the offending ~/.ssh/known_hosts entry:
>> 
>> ()
>> $ ssh-keygen -H -F  | awk '{ print $NF }'
>> dGhpcyBpcyB2ZXJ5IHZlcnkgdmVyeSB2ZXJ5IHZlcnkgbG9uZyBob3N0IGtleQ==
>> 
>> Then on the OS X server, grep for that in /etc/ssh/*.pub
>> 
>> I bet the key negotiated by conch is not an ECDSA key but rather an
>> RSA key.  If this is all the case, then I think you've found a key
>> that LibreSSL supports but your client's libssl (which conch calls
>> into via cryptography) does not.  What version of libssl do you have?
>> 
>> If any of this is helpful or relevant I'll ask more questions in the
>> ticket.
> 
> I think there might be a regression in 16.6.0.
> 
> For every version up to 16.6.0, I can do 'conch twistedmatrix.com 
> ' in a shell and it works fine.
> 
> On 16.6.0, I get:
> 
> Connection to twistedmatrix.com  closed.
> conch: exiting with error [Failure instance: Traceback (failure with no 
> frames): : ('bad host key', 9)
> ]
> 
> instead.
> 
> Worth noting: the keys I have for twistedmatrix.com 
>  are RSA keys.
> 
> What did we add recently that changes key parsing?

The offending commit is 8164d89104a453947215b9296e8b406f15e63252.  Clearly 
something went wrong when introducing ECDSA parsing.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] conch problem with ecdsa-sha2-nistp256 host key?

[Glyph Lefkowitz]

> On Dec 1, 2016, at 7:01 PM, Mark Williams  wrote:
> 
> On Thu, Dec 01, 2016 at 05:11:37PM -0800, Craig Rodrigues wrote:
>> Hi,
>> 
>> I filed this bug:
>> https://twistedmatrix.com/trac/ticket/8931
>> 
>> At least for me, conch fails to parse a host key created by OpenSSH
>> in ~/.ssh/known_hosts
>> which is of type ecdsa-sha2-nistp256.
>> 
>> Anyone have an idea as to how to fix this?
>> 
> 
> As usual you've found a fantastically interesting issue.
> 
> This is conch, the client, right?  I'm guessing so because
> ~/.ssh/known_hosts contains the servers the ssh client trusts.
> (Specifically, among other things it contains a hostname and that
> host's sshd server's public key fingerprint).
> 
> If it is conch, the-client, then deleting the offending entry from
> ~/.ssh/known_hosts and getting a new one makes sense.  That's because
> sshd usually generates a couple of different keys in case clients
> don't support the latest and greatest technology.
> 
> I think deleting the entry in ~/.ssh/known_hosts allows conch to ask
> the server for a different key that it *can* understand.  You should
> be able to find out which server key conch negotiated by doing thing
> following after deleting the offending ~/.ssh/known_hosts entry:
> 
> ()
> $ ssh-keygen -H -F  | awk '{ print $NF }'
> dGhpcyBpcyB2ZXJ5IHZlcnkgdmVyeSB2ZXJ5IHZlcnkgbG9uZyBob3N0IGtleQ==
> 
> Then on the OS X server, grep for that in /etc/ssh/*.pub
> 
> I bet the key negotiated by conch is not an ECDSA key but rather an
> RSA key.  If this is all the case, then I think you've found a key
> that LibreSSL supports but your client's libssl (which conch calls
> into via cryptography) does not.  What version of libssl do you have?
> 
> If any of this is helpful or relevant I'll ask more questions in the
> ticket.

I think there might be a regression in 16.6.0.

For every version up to 16.6.0, I can do 'conch twistedmatrix.com' in a shell 
and it works fine.

On 16.6.0, I get:

Connection to twistedmatrix.com closed.
conch: exiting with error [Failure instance: Traceback (failure with no 
frames): : ('bad host key', 9)
]

instead.

Worth noting: the keys I have for twistedmatrix.com are RSA keys.

What did we add recently that changes key parsing?

-glyph___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python