micah anderson: > Chris Knadle <[email protected]> writes: > >> micah: >>> Chris Knadle <[email protected]> writes: >> >>>> I'm currently updating my 1.2.10-1 prepared upload for Debian with a patch >>>> for #787384, which I just did for the package in my repo only for Sid, >>>> because the new zeroc-ice hasn't transitioned to Stretch yet AFAIK. >>> >>> The reason I'm really interested in this is because of the PFS cipher >>> support. Unfortunately, it seems like this isn't particularly useful >>> unless things are built from the git head at the moment, and maybe that >>> support isn't even finished. It would be great if this could be brought >>> into the debian packages (even if it might need to be done before 1.3 is >>> released), see https://github.com/mumble-voip/mumble/issues/1811 >> >> I'm really interested in mumble in terms of encryption/privacy/integrity >> too, so I'd love to get PFS support but in reading the bug it looks like >> that's not possible for now. Upstream has specifically requested I only >> release the stable 1.2 builds (the non-snapshot+cherry-pick-patches release >> for wheezy that Ron Lee made has been particularly painful for upstream) and >> avoid uploading any of the 1.3 "snapshot" builds until they release a stable >> version, and #1811 above states that the mumble 1.2 releases are bound to Qt >> 4... and sounds like Qt 4 can't do PFS > > Yeah, I think you are right. > > As an aside, the Qt 4 problem shouldn't be an issue because QT 5 is in > Debian now.
Yes but it's kind of a moot point: mumble 1.2.x is Qt 4 only. Qt 5 being in Sid means we're ready to transition to it once mumble 1.3.x is released. [1.3.x will be compatible with Qt 4 or Qt 5, 1.4.x will be Qt 5 only.] >> Mumble upstream also have some Qt 4 patches to add TLS 1.1 and 1.2 support, >> but the way they work is to redefine QSsl::TlsV1 to mean "TLS 1.0 or later" >> and they don't recommend upstream distributions try to use these patches. >> This is explained in: >> >> http://blog.mumble.info/mumble-1-2-9/ >> >> The only good news is that with the 1.2.10-1 release I'm about to upload, >> the sslCiphers can be specified in the mumble-server.ini file. [That's >> probably important enough that I should add a note about this to the NEWS >> file.] > > Yeah, I've been testing this version against the same server version, > and trying to set the sslciphers option in the murmurd config file, it > seems to set it, but I can't seem to get the client to pick up those > preferred ciphers, and I'm not sure why. Hmm. Okay. I haven't played with the option (with mumble) yet.. specifying a list SSL ciphers can be tricky because of the notation shorthands that are available. The .ini file suggests using 'openssl ciphers <string>' to check the resulting cipher list. Likewise check that the cipher list you want is actually available on both sides. >> BTW: in the "Advanced" settings under "Network" in the mumble client you can >> use "Force TCP mode" so that mumble could be used over Tor and then starting >> mumble in a terminal with 'torify mumble'. [That works! :-)] > > You can also not set "Force TCP mode" and just use 'torsocks mumble' - > that works fine too (even with .onion addresses!) Mumble seems to > automatically switch to one mode over the other, if it can do it, so > maybe the Force mode would just make it faster in figuring this out? I > just know it was pretty fast in figuring it out for me. I'm glad this works too. If I used firewall to block UDP traffic and force the use of Tor then this would probably be okay, but other than that if I intended to do mumble over Tor I'd likely use "Force TCP mode" to try to insure I didn't accidentally leak my IP via sending UDP traffic in a connection attempt. >> Re: integrity: a while ago I changed the the debian/watch file to have uscan >> check OpenPGP signatures of the upstream releases. And with 1.2.10-1 I'm >> switching debian/rules to 'dh' in an effort to get reproducible builds. > > that is great to hear, thanks for doing those changes! You're welcome -- trying to do what I can -- Chris Knadle [email protected]
