Project

General

Profile

Task #1916

nfd-status: display NFD version

Added by Alex Afanasyev about 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Category:
Tools
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
1.00 h

Description

In nfd-status and nfd-status-http-server, display NFD software version from NfdVersion field in ForwarderStatus packet.


Related issues

Blocked by NFD - Task #2003: StatusServer: include NFD version in NfdVersion fieldClosed

History

#1 Updated by Davide Pesavento about 5 years ago

The de facto standard is to use the first 7 hex digits of the commit hash. However, I suggest just using git describe --always which automatically takes care of abbreviating the hash without compromising uniqueness.

#2 Updated by Alex Afanasyev about 5 years ago

The problem is that when somebody cloned with --depth 1, there is only one commit and git describe wouldn't know what length is enough for uniqueness. My client (gitx) shows 10 hex digits, that's why I chose 10 in the description.

The current implementation uses git describe (but with slightly different options), so it not exactly follows the proposal here :)

#3 Updated by Davide Pesavento about 5 years ago

Alex Afanasyev wrote:

The problem is that when somebody cloned with --depth 1, there is only one commit and git describe wouldn't know what length is enough for uniqueness. My client (gitx) shows 10 hex digits, that's why I chose 10 in the description.

git itself uses 7 hex digits in the shallow clone case (I just checked with git clone --depth 1 && git describe --always).

I don't understand what the problem is with using --always unconditionally.

#4 Updated by Junxiao Shi about 5 years ago

The NfdVersion component in ForwarderStatus is intended to show the API version of NFD, not the software version.

Software version of NFD cannot be obtained by nfd-status without a change to ForwarderStatus protocol, and I don't think this change is needed.

Software version of nfd-status is readily available with nfd-status -V, and it is usually but not always same as software version of NFD.

It is dangerous to display software version of either program on HTTP status page, because the exposed software version would allow an attacker to exploit a weakness in that specific software version.

#5 Updated by Junxiao Shi almost 5 years ago

  • Status changed from New to Rejected
  • Start date deleted (08/22/2014)

I'm rejecting this Task because @Alex did not reply to the concern in note-4 in the past 2 weeks.
If there is an answer, please reopen this Task.

#6 Updated by Alex Afanasyev almost 5 years ago

  • Status changed from Rejected to New

It is pointless to show just version number, given the rate we change it.

The idea of reporting specific version is to discover what has been installed on the host. Personally, I needed this to know which version of nfd is running on the testbed node.

I do not worry about any danger of exposing version. First, we are not at the stage to be worrying about such minor things. Second, even without knowing specific version, anybody can simply run set of known exploits. Hiding the version only harm us, since we cannot easily obtain and monitor the exact cersion installed.

I'm ok with changin the dataset. We could include both versions: one API and one actual version of the code. Or simply include version of the code.

#7 Updated by Davide Pesavento almost 5 years ago

Alex Afanasyev wrote:

I do not worry about any danger of exposing version. First, we are not at the stage to be worrying about such minor things. Second, even without knowing specific version, anybody can simply run set of known exploits. Hiding the version only harm us, since we cannot easily obtain and monitor the exact cersion installed.

I agree with Alex on this point.

I'm ok with changin the dataset. We could include both versions: one API and one actual version of the code. Or simply include version of the code.

I don't think we really want to give a potentially different version number to each tool/binary in NFD repo. Therefore, the HTTP server can just report its own version (or nfd-status's version) as the "code version", which makes things much simpler (no need to put it in the dataset). The "API version", on the other hand, can be kept separate.

#8 Updated by Junxiao Shi almost 5 years ago

See note-4:

Software version of nfd-status is readily available with nfd-status -V, and it is usually but not always same as software version of NFD.

And notice this issue is about nfd-status, not the HTTP server.

So there's nothing left to do.

#9 Updated by Davide Pesavento almost 5 years ago

Junxiao Shi wrote:

See note-4:

Software version of nfd-status is readily available with nfd-status -V, and it is usually but not always same as software version of NFD.

Well, if they're not, we should align the versions and make sure they stay aligned (e.g. all binaries use the same version number generated by waf)

#10 Updated by Alex Afanasyev almost 5 years ago

The problem described is with http status server. The way I though to fix it was via changing nfd status output, which is requested by status server. I still think that in the long term it is a better approach (such a daset can be requested in the future remotely). Buy I'm ok directly returning version of status server, since it is normally be the same version of te running nfd.

#11 Updated by Alex Afanasyev almost 5 years ago

I'm actually start to agree with an old comment, I think Davide made. There is no real value in "API" version and we can simply remove it and keep only commit-specific version.

#12 Updated by Junxiao Shi almost 5 years ago

API version is necessary.
After 1.0.0 release, API version would follow semantic versioning spec.

Software version can appear in addition to API version.
I'll update ForwarderStatus protocol for a new field.

#13 Updated by Alex Afanasyev almost 5 years ago

I may be wrong, but I don't see how it can be used. I see its value for the library, but no so much for the forwarder.

what use cases for it you have in mind?

#14 Updated by Junxiao Shi almost 5 years ago

A client can obtain the API version of the forwarder, and decide how to interact with this forwarder.
It's a separate question on how to obtain the API version, but executing a command is one way.

#15 Updated by Junxiao Shi almost 5 years ago

  • Blocked by Task #2003: StatusServer: include NFD version in NfdVersion field added

#16 Updated by Junxiao Shi almost 5 years ago

  • Subject changed from nfd-status: Display detailed version instead or in addition to basic version to nfd-status: display SoftwareVersion
  • Description updated (diff)
  • Estimated time set to 1.50 h

#17 Updated by Davide Pesavento almost 5 years ago

I really don't see the need for all this complexity.

One version number is enough. One version for the whole NFD repo, the same version that is used to tag releases, shared across all tools and daemons, which is also equivalent to the "forwarder API version" (whatever that means), and incremented according to the semantic versioning scheme. Period.

Using more than one version number only leads to confusion (think about user support), is very difficult to maintain, and brings no benefit.

#18 Updated by Junxiao Shi almost 5 years ago

A version number conforming to Semantic Versioning has the form MAJOR.MINOR.PATCH.

git --describe is unable to supply such a version number automatically.

Are you suggesting that EVERY commit must change the version number in wscript?

#19 Updated by Davide Pesavento almost 5 years ago

Junxiao Shi wrote:

A version number conforming to Semantic Versioning has the form MAJOR.MINOR.PATCH.

git --describe is unable to supply such a version number automatically.

Quoting the same document you linked:

9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

It seems to me that the output of git describe is perfectly valid (excluding the first "v" which is part of the tag). The "lower precedence" part could be a problem, but I don't think that part of the specification has much importance. If you think that's a problem, we can simply replace the first hyphen with a plus sign (wrt point 10 of the semver spec).

#20 Updated by Junxiao Shi almost 5 years ago

  • Subject changed from nfd-status: display SoftwareVersion to nfd-status: display NFD version
  • Description updated (diff)
  • Estimated time changed from 1.50 h to 1.00 h

#21 Updated by Junxiao Shi almost 5 years ago

  • Assignee set to Hila Ben Abraham

#1916 and #2003 shall be worked on together and merged together, otherwise the backwards-incompatible change in ndn::nfd::ForwarderStatus will cause compilation failure.

#22 Updated by Hila Ben Abraham almost 5 years ago

  • % Done changed from 0 to 100

#23 Updated by Hila Ben Abraham almost 5 years ago

  • Status changed from New to Code review

#24 Updated by Junxiao Shi almost 5 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF