feat: JioTV Go build for JioFiber

[itsyourap]

Feature description

JioTV Go build for JioFiber routers like JCOW414 and JCO4032 (mips).

Solution

• Use this toolchain to build JioTV Go using the following command:

  LD_LIBRARY_PATH=mipsel-buildroot-linux-uclibc-toolchain-2015.08.1/usr/lib CC=mipsel-buildroot-linux-uclibc-toolchain-2015.08.1/usr/bin/mipsel-buildroot-linux-uclibc-gcc GOARCH=mipsle GOOS=linux go build -o bin/jiotv_go-jiofiber-mips .

• A working GitHub Actions workflow yml can be found here

Additional context

❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗❗

Issue: JioFiber routers don't have a master keystore to verify TLS certs hence we need to find an alternative method to support HTTPS traffic through JioTV Go on JioFiber.

To fix the TLS certificate issue we can hardcode the public certificates of the required HTTPs traffic servers into JioTV Go's code to verify using the custom certificate pool. I have a working solution here

Acknowledgements

• [X] I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I filled out all of the requested information in this issue properly.

[rabilrbl]

@itsyourap

1. Have you verified the public certificate in utils expires in some 203x year
2. I wouldn't put cert file in utils package. Instead under assets in root directory
3. I don't think we should have that logic to read file in GetRequestClient because it's called frequently (lead to poor performance as file operations are expensive). Instead can we have a build option in go (maybe env var during build) stating it's a JF build and include embedded cert file? We will have a JF specific binary either way, so why not just do this?

[itsyourap]

Have you verified the public certificate in utils expires in some 203x year

All of the certificates except the GlobalSign ones expire in some 203x year. The GlobalSign certificates expire in 2025. The GlobalSign certificates are used by jiotvmblive.cdn.jio.com and jiotv.catchup.cdn.jio.com

I wouldn't put cert file in utils package. Instead under assets in root directory

Sure. That won't be a problem. I will fix it.

I don't think we should have that logic to read file in GetRequestClient because it's called frequently (lead to poor performance as file operations are expensive). Instead can we have a build option in go (maybe env var during build) stating it's a JF build and include embedded cert file? We will have a JF specific binary either way, so why not just do this?

Yes! That can be done. I will work on it.

[rabilrbl]

But expiring in 2025 means every year someone has to update it? How is that a good idea for project maintenance? We should focus for the long term fix

Let's do http instead of insecure https. I believe they don't redirect to https. Let's go for this if we don't have any better ideas. Under the constant package that we discussed earlier. let's have JF specific API routes

[itsyourap]

We could also define some GitHub Actions workflow to automatically update the latest certificates available for the specified URLs.

I will let you know within a few days.

[rabilrbl]

We could also define some GitHub Actions workflow to automatically update the latest certificates available for the specified URLs.

I will let you know within a few days.

That'll collide with our release cycle. We can't have releases for all devices only to update certs for JF. We can't have JF specific releases too.

Let's not go this path

[itsyourap]

Alright then

[itsyourap]

What we also could do is get the certs PEM file dynamically from http://curl.se/ca/cacert.pem - These certs are extracted from Mozilla's root certificates and are enough to verify all the HTTPS sites. We could download the file in some writable locations of the JF like /flash2.

Then in code we could check if the file exists, if it does then use the certs from it and if it doesn't then download it and then use it.

We also have some docs at https://curl.se/docs/caextract.html to let us determine when the certs have changed and redownload it.

I believe getting the certs is better than going pure HTTP.

[rabilrbl]

What we also could do is get the certs PEM file dynamically from http://curl.se/ca/cacert.pem - These certs are extracted from Mozilla's root certificates and are enough to verify all the HTTPS sites. We could download the file in some writable locations of the JF like /flash2.

Then in code we could check if the file exists, if it does then use the certs from it and if it doesn't then download it and then use it.

We also have some docs at https://curl.se/docs/caextract.html to let us determine when the certs have changed and redownload it.

I believe getting the certs is better than going pure HTTP.

Confirm if it actually contains certs for Jio in their 200kb size and go ahead if you can implement this at build time I don't want other devices to be bothered with this.

Also how many users do you think we'll have for a JF router? Barely 10? Will it be that important?

The reason for including jf in official build because i thought it's only compiling to that mips arch binary

Now i am thinking of not supporting all these hacks for only a few users. How is this all justified?

[itsyourap]

Yes you are right! I think it's better to keep JFC-JioTV in a separate repo just as it is now.

[rabilrbl]

Thanks