[Bug 795501] New: SRT Passphrase not working

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=795501

            Bug ID: 795501
           Summary: SRT Passphrase not working
    Classification: Platform
           Product: GStreamer
           Version: 1.14.0
                OS: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: marcus.pennington at sohonet.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

As discussed on the mailing list here:
https://lists.freedesktop.org/archives/gstreamer-devel/2018-April/067657.html

It appears that the passphrase parameter for the SRT plugins are not
functioning correctly.

Copied from my original post in the mailing list:

We've been playing with the new SRT plugins as part of gst-plugins-bad and
all seems well apart from a couple of features.

Using it like so on the client (sender):
... srtclientsink passphrase=eb55dec3c22f4e0879baadfe2fd50151
uri=srt://10.10.10.10:6000...

And on the server (listener):
... srtserversrc passphrase=eb55dec3c22f4e0879baadfe2fd50151
uri=srt://:6000...

The first one being the passphrase parameter. At first, I assumed it was
working fine and the stream was encrypted, but after accidentally setting
the wrong password on the srtserversrc, to my surprise, the stream sill
worked. After some investigation, it seems that it works with or without a
passphrase, even if the passphrase is set on the srtclientsink.

I've tried everything it feels like to try and get this to work, this
includes:
- Setting the key-length to 16 even though that's the default
- Trying the other key-lengths
- Wrapping the passphrase in "quotes"
- Using different passphrases with different lengths
- Using only integers for the passphrase instead
... all on both sides of the pipeline.

However, it always seems that the stream is being sent unencrypted. Even
with debug level set on both plugins, there are no complaints or logs to
suggest anything is wrong.

I've scoured the web for examples but none can be found where the
passphrase is being used. So I'm now thinking there is either a bug or we
are doing something incorrectly here.

If we are doing something wrong, then I would have thought that something
should at least error or give a warning, rather than allow the stream to go
through unencrypted...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.