Version Info on GUI #1762

New Issue

Bouni · 2021-01-12T14:43:31Z

Bouni commented

2021-01-12 14:43:31 +00:00

Is there a reason that you do not show version info on the GUI?

I would submit a PR but only if there are no arguments against showning the version ...

Is there a reason that you do not show version info on the GUI? I would submit a PR but only if there are no arguments against showning the version ...

konrad commented

2021-01-12 17:44:49 +00:00

No, not a real reason. Just haven't gotten around in doing this yet.

I think a popup like the keyboard shortcuts, but accesible from the user menu on the top left would be a good way to do this.

I'd happily accept a PR :)

No, not a real reason. Just haven't gotten around in doing this yet. I think a popup like the keyboard shortcuts, but accesible from the user menu on the top left would be a good way to do this. I'd happily accept a PR :)

konrad added the

kind/feature

label 2021-01-12 17:44:54 +00:00

UnsolvedCypher commented

2021-04-15 00:49:01 +00:00

@Bouni are you still interested in creating the PR?

Bouni commented

2021-04-15 05:17:59 +00:00

To be honest, I totally forgot about this 😅
If you want to submit a PR for this, go on, if not let me know and I'll see if I can find some spare time to do it ...

To be honest, I totally forgot about this :sweat_smile: If you want to submit a PR for this, go on, if not let me know and I'll see if I can find some spare time to do it ...

👍 1

danner26 commented

2021-04-15 21:17:17 +00:00

I suggest we make this configurable, wether it is shown or not. A common attack vector can be finding an old version of software that contains a security bug. Allowing this to be disabled, if enabled by default, would allow for us to be a little less parinoid ;)

Or only show versions on pages that are behind authentication, aka disallow version to be shown or transmitted from the api if not authenticated.

I suggest we make this configurable, wether it is shown or not. A common attack vector can be finding an old version of software that contains a security bug. Allowing this to be disabled, if enabled by default, would allow for us to be a little less parinoid ;) Or only show versions on pages that are behind authentication, aka disallow version to be shown or transmitted from the api if not authenticated.

konrad commented

2021-04-15 21:20:55 +00:00

Currently you get the frontend version in the console when accessing the frontend and the api version when accessing /api/v1/info. While we could protect the api version endpoint to only allow access for logged in users I don't see how we reasonably could hide it for the frontend as it has to be embedded in the final js bundle. A scanner could find that.

I thought about showing the info in the settings or in a new popup accessible from the user menu so it wouldn't really be too accessible without being logged in.

Currently you get the frontend version in the console when accessing the frontend and the api version when accessing `/api/v1/info`. While we could protect the api version endpoint to only allow access for logged in users I don't see how we reasonably could hide it for the frontend as it has to be embedded in the final js bundle. A scanner could find that. I thought about showing the info in the settings or in a new popup accessible from the user menu so it wouldn't really be too accessible without being logged in.

danner26 commented

2021-04-15 22:03:29 +00:00

A frontend version isnt really the issue, it is the backend version that needs to be protected in my opinion. Do the frontend versions differ from the backend version at any given time? If so then it is mute to worry about the bundles js version number that is already there (since that is designating the frontend version).

If the versions always match then ultimately there would need to be modification to this feature in order to make the version something that is loaded from the backend (therefore no longer bundled in the js).

A frontend version isnt really the issue, it is the backend version that needs to be protected in my opinion. Do the frontend versions differ from the backend version at any given time? If so then it is mute to worry about the bundles js version number that is already there (since that is designating the frontend version). If the versions always match then ultimately there would need to be modification to this feature in order to make the version something that is loaded from the backend (therefore no longer bundled in the js).

UnsolvedCypher commented

2021-04-16 04:33:25 +00:00

I think it may be overkill to try to obscure the version number to that extent. If there was such a vulnerability, it would not at all be difficult to find the source code for the frontend that was released around the same time as the vulnerable backend and programatically check if an app is serving that same source code.

If you scroll down on this page a little you will see that Gitea has its version number printed at the bottom of the screen. Ultimately, the only way to ensure security is to keep the application up to date regularly.

I think it may be overkill to try to obscure the version number to that extent. If there was such a vulnerability, it would not at all be difficult to find the source code for the frontend that was released around the same time as the vulnerable backend and programatically check if an app is serving that same source code. If you scroll down on this page a little you will see that Gitea has its version number printed at the bottom of the screen. Ultimately, the only way to ensure security is to keep the application up to date regularly.

konrad commented

2021-04-16 12:15:12 +00:00

While somewhat independent the api and frontend should be roughly the same version to function properly. So if you have the version of one of them, you can guess the version of the other.

Ultimately, the only way to ensure security is to keep the application up to date regularly.

I definitely agree. "Security by obscurity" never works out great.

While somewhat independent the api and frontend should be roughly the same version to function properly. So if you have the version of one of them, you can guess the version of the other. > Ultimately, the only way to ensure security is to keep the application up to date regularly. I definitely agree. "Security by obscurity" never works out great.

danner26 commented

2021-04-16 13:02:16 +00:00

I agree that keeping it up to date is the best way, but exposing information such as a version can "aid an attacker to craft targeted attacks against the service"

Refer to here. I worked with Grafana extensively to resolve their version of this. In fact, the main reason why I mentioned this is because it is a valid security concern in my opinion. Totally upto yall though, since I dont really have time to make any PR's at the moment.

https://github.com/grafana/grafana/issues/12925

I agree that keeping it up to date is the best way, but exposing information such as a version can "aid an attacker to craft targeted attacks against the service" Refer to here. I worked with Grafana extensively to resolve their version of this. In fact, the main reason why I mentioned this is because it is a valid security concern in my opinion. Totally upto yall though, since I dont really have time to make any PR's at the moment. https://github.com/grafana/grafana/issues/12925

Bouni commented

2021-05-04 10:37:09 +00:00

If I get it this reight, the prefered way would be to have the /api/v1/info a protected endpoint so that only logged in users can use it and have a popup like for the keyboard shortcuts that shows the version info, right?

That would prevent the problem with exposing the info to the world and on the other hand give the logged in user a way to see the versin info.

I'll not start working on a PR unless we come to an agreement about what way to go 😉

If I get it this reight, the prefered way would be to have the /api/v1/info a protected endpoint so that only logged in users can use it and have a popup like for the keyboard shortcuts that shows the version info, right? That would prevent the problem with exposing the info to the world and on the other hand give the logged in user a way to see the versin info. I'll not start working on a PR unless we come to an agreement about what way to go :wink:

konrad commented

2021-05-04 16:47:34 +00:00

/api/v1/info has to be public because that also exposes other information required for unauthenticated purposes. We could remove the version from it and add a new endpoind /api/v1/version behind authentication though.

`/api/v1/info` has to be public because that also exposes other information required for unauthenticated purposes. We could remove the version from it and add a new endpoind `/api/v1/version` behind authentication though.

konrad referenced this issue from a commit

2021-07-06 15:05:38 +00:00

Add showing version info in GUI

konrad closed this issue

2021-07-06 15:05:38 +00:00

konrad commented

2021-07-06 15:05:51 +00:00

Implemented in f3715c7900

Implemented in https://kolaente.dev/vikunja/frontend/commit/f3715c79009efec09bce0e111533066a09043663

konrad referenced this issue from a commit

2024-02-07 14:00:33 +00:00

chore(deps): update dependency vitest to v0.8.3 (#1762)