search

JioTV-Go / jiotv_go

Unlock the magic of JioTV across all your devices, without the need for the JioTV App. Crafted with love in Golang for a delightful blend of speed and efficiency! 🌟✨
https://jiotv_go.rabil.me/
Other
386 stars 100 forks source link

feat: JioTV Go build for JioFiber #431

Closed itsyourap closed 2 months ago

itsyourap commented 2 months ago

Feature description

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

Solution

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

rabilrbl commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Alright then

itsyourap commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

rabilrbl commented 2 months ago

Thanks