[mythtv] [mythtv-commits] Ticket #8877: Add unique token check to protocol handshake

Robert McNamara robert.mcnamara at gmail.com
Tue Sep 7 02:46:30 UTC 2010


On Mon, Sep 6, 2010 at 7:38 PM, Chris Adams <rocket at extremelan.net> wrote:
> On Tue, Sep 7, 2010 at 8:01 AM, MythTV <mythtv at cvs.mythtv.org> wrote:
>> #8877: Add unique token check to protocol handshake
>> ----------------------------------+-----------------------------------------
>>     Reporter:  wagnerrp          |       Owner:  cpinkham
>>         Type:  enhancement       |      Status:  new
>>     Priority:  minor             |   Milestone:  0.24
>>    Component:  MythTV - General  |     Version:  Trunk Head
>>     Severity:  medium            |    Keywords:
>> Ticket locked:  0                 |
>> ----------------------------------+-----------------------------------------
>>  This patch adds a randomly generated token to the MYTH_PROTO_VERSION call.
>>  The purpose of this is to provide a unique token for each protocol version
>>  to check against, to ensure the client actually speaks the proper
>>  protocol, and isn't simply responding with the version handed out by a
>>  previous connection.  The current string is just a randomly generated
>>  8-digit hex string.
>>
>>  This was motivated by a recent discussion in the mailing list where the
>>  'libcmyth' library was touted as a well maintained interface for accessing
>>  MythTV, while it has not actually been updated since protocol version 44.
>>
>> --
>> Ticket URL: <http://svn.mythtv.org/trac/ticket/8877>
>> MythTV <http://www.mythtv.org/>
>> MythTV Media Center
>
> No one touted it as a well maintained interface to myth. It was only
> pointed out that it works.

Actually, the words "well maintained" specifically were used.  If well
maintained = 17 protocol versions old, but still claims to speak
whatever protocol version of myth it talks to, there is a real problem
(and a real danger to that user's data).

> Despite staggering efforts of developers the frontend continues to lag
> behind the competition in some important ways. Most notably,
> mythfrontend hasn't received years of work on flashy animated themes
> and isn't compatible with as many video formats and containers. On the
> other hand the backend is a truly amazing piece of software.

Myth is every bit as compatible with containers and formats as every
other ffmpeg-derived media player, XBMC included.  It also includes a
centralized method of storing videos and recordings that simplifies
setup (Storage Groups) and access to the same media libraries across a
network (versus having to recreate or import it at every seat like
XBMC).  With that in mind, I'll take the Myth frontend any day-- we
have some ways to go on the UI, setup, and settings front, but we are
making plenty of progress, with concrete plans in place for the near
future.

> So in 2010 MythTV is: amazing backend coupled tightly to a frontend
> lagging behind the competition. Personally I'd rather do a bit of work
> and ditch the frontend for a superior alternative.

Not gonna happen.  We would welcome your work on themes and the UI
library, however.

> This patch is designed to deprive people of alternatives - so it goes
> against the whole point of open source. Why would you not want people
> to mix and match so they get the best stuff open source has to offer?

We don't care if they do-- but if they claim to speak protocol "x",
they just need to have done the homework to actually do so.  This
patch will not prevent third party frontends from functioning, it will
just compel them to *actually* speak the protocol version that they
claim to, rather than lying about it.  We have a responsibility to
protect data within the Myth ecosystem, so that we are not on the
hook/blamed when that user's data gets fried because their
"alternative frontend" claims to speak a language it doesn't.

Robert


More information about the mythtv-dev mailing list