Skip to content
This repository was archived by the owner on Jul 24, 2020. It is now read-only.

Display version somewhere in the admin view? #560

Merged
merged 3 commits into from
Jul 7, 2014

Conversation

shippy
Copy link
Contributor

@shippy shippy commented Jul 7, 2014

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. :-)

@mnquintana
Copy link
Contributor

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...

@mnquintana mnquintana added this to the 3.4.0 milestone Jul 1, 2014
@shippy
Copy link
Contributor

shippy commented Jul 7, 2014

It would be cool if we could use git describe, as described here. Unfortunately, this is the current output:

02:12 PM $ git describe
v3.1.0.alpha10-568-g0c5d5df

@orenyk
Copy link
Contributor

orenyk commented Jul 7, 2014

That's why we need clean tags for version numbers :-)
On Jul 7, 2014 2:13 PM, "Simon Podhajsky" [email protected] wrote:

It would be cool if we could use git describe
https://www.kernel.org/pub/software/scm/git/docs/git-describe.html, as
(described here)[
http://blog.danielpietzsch.com/post/1209091430/show-the-version-number-of-your-rails-app-using-git].
Unfortunately, this is the current output:

02:12 PM $ git describe
v3.1.0.alpha10-568-g0c5d5df


Reply to this email directly or view it on GitHub
#560 (comment)
.

@shippy
Copy link
Contributor

shippy commented Jul 7, 2014

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:

02:15 PM $ git describe --tags
v3.3.0-rc.1-29-g0c5d5df

Consequently, here's what I'm adding to environment.rb:

APP_VERSION = `git describe --tags` unless defined? APP_VERSION

@orenyk
Copy link
Contributor

orenyk commented Jul 7, 2014

Looks good, I'm going to make the text on the settings page a bit bigger but nice job :-)

orenyk added a commit that referenced this pull request Jul 7, 2014
Display version somewhere in the admin view?
@orenyk orenyk merged commit 4f21af1 into development Jul 7, 2014
@squidgetx squidgetx deleted the 560_display_version branch July 15, 2014 19:36
@orenyk
Copy link
Contributor

orenyk commented Jul 29, 2014

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?

@dgoerger
Copy link
Contributor Author

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.

@orenyk
Copy link
Contributor

orenyk commented Jul 30, 2014

Agreed, I'll issue PRs for both release-v3.4 and master.

@shippy
Copy link
Contributor

shippy commented Jul 30, 2014

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.

@orenyk
Copy link
Contributor

orenyk commented Jul 30, 2014

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?

@dgoerger
Copy link
Contributor Author

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.

@orenyk
Copy link
Contributor

orenyk commented Jul 30, 2014

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.

@dgoerger
Copy link
Contributor Author

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.

@mnquintana
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants