-
Notifications
You must be signed in to change notification settings - Fork 57
Display version somewhere in the admin view? #560
Conversation
That's a good idea! I'm not sure what the standard practice for version numbers is, but it seems like we should initialize a constant with a string value of the version number somewhere (in an initializer?). But it would be nice if there were a way to automatically pull the version number from the git tag... |
It would be cool if we could use git describe, as described here. Unfortunately, this is the current output:
|
That's why we need clean tags for version numbers :-)
|
Okay, it seems that we haven't been using annotated tags lately, which explains the faulty output above. Luckily, this option allows us to display the latest lightweight tag:
Consequently, here's what I'm adding to
|
Looks good, I'm going to make the text on the settings page a bit bigger but nice job :-) |
Display version somewhere in the admin view?
I just realized that patrons and checkout persons can't see the version number in the footer. I'm assuming this was intentional; is there a reason why we're hiding the version number from those users? |
I suspect it was to avoid clutter, however I think generally all users should be able to see the version number to be able to report problems with the code. |
Agreed, I'll issue PRs for both |
My internal rationalization of why version display was only limited to privileged users was that displaying the version publicly also gives the potential attacker a point of entry, should the Reservations instance in question be behind on some critical bugfixes. We never did actually have a conversation where this would be stated, though. |
You're back! I see your point and I guess I'm torn on this one; on the one hand I don't feel like our app is that critical that the extra vulnerability carries high risk, but at the same time that's not necessarily a valid design justification. @dgoerger @squidgetx thoughts? |
I personally subscribe to the philosophy that users should have transparency in their software and, if it is unsecure and out of date, they should be able to tell the admin to get their act together. It's important when considering any form of "security through obscurity" (airquotes because I don't believe obscurity is secure) to note that hackers will try known exploits regardless of whether or not they know the version number (if it's patched, boo-hoo, five minutes wasted; if not, jackpot), while concealing the version number from patrons leaves them vulnerable because an informed user can't demand that the webmaster pull the update. |
OK I buy that, it puts the burden on the admins rather than on us, which I think is fair. Unless anyone has any objection, I'll merge the PRs tonight. |
Displaying the version number also helps patrons who are inclined to report bugs. Oren and I were going to report a bug with ITS Jenkins, until we realized upstream had already fixed it by examining the changelog and publicly-displayed version numbers. |
I think we should display it. Would-be hackers could easily surmise that most instances of Reservations would be running the latest tagged version on GitHub, so we wouldn't really been obscuring much by not showing it, and I think it's useful to show it to regular users. |
Should we display the version number somewhere in the admin / superuser view? It would be helpful when receiving "bug reports" from users if they could indicate to us which point-release they're on. :-)