Open consideRatio opened 2 years ago
If we're concerned about potentially revealing that we're running a version with a secvuln we could just expose the first two components (1.20
) instead of the full version.
If we're concerned about potentially revealing that we're running a version with a secvuln we could just expose the first two components (1.20) instead of the full version.
That is the version of relevance to a large extent, and could for example be used to automatically test template rendering against the relevant version as considered in https://github.com/jupyterhub/mybinder.org-deploy/issues/2206
I looked into this manually and concluded, at this point in time that:
Turing: v1.21 GKE Staging: v1.21 GKE Prod: v1.21 OVH: v1.20
I think exposing the major.minor version would be helpful. But, I think we can leave out patch and build details as I don't already know that could be helpful and as you say, that could provide a bit much information for those looking to know how to exploit a known vulnerability.
When maintaining the mybinder.org-deploy federation, it is helpful to know what version various k8s clusters are at as that can dictate what upgrades are possible. Should binderhub expose that alongside binderhub version etc in the version endpoint?
This is an idea @manics came up with in https://github.com/jupyterhub/binderhub/pull/1493#issuecomment-1138367637, and I think it would be very relevant to know that overall. Right now, I'd like to know it, but it is quite a hurdle to get that info I think. I believe I'd need to manually setup credentials against each cluster and check.
https://github.com/jupyterhub/binderhub/blob/656204bb62d46be51fc7fb79cc5d7600b71a7614/binderhub/base.py#L236-L254