Add support for hash sequence

[langbeck]

Adding support for HashSequenceStart, SequenceUpdate and SequenceComplete.
Closes issue #179

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[langbeck]

@googlebot I signed it!

[langbeck]

Hi @josephlr
I'll send another commit with some tests once you confirm that the proposed API seems fine.

[chrisfenner]

Thanks for the change! This looks good to me, I have a structural comment (interested in @josephlr or @twitchy-jsonp opinions on it as well) and one optional request.

[langbeck]

Do you guys want me to change anything else?
This repo does auto-merge once I get the approval of all 3 reviewers?

[twitchy-jsonp]

Sorry for the delay, I usually wait for another reviewer before merging.

In any case, can you rebase onto master? Github might be able to do it automatically.

[langbeck]

Rebased!

---

@twitchy-jsonp And how about the enum discussion above?
Do still you want me to change to numerical ordering?

Note that everytime someone ask me to change something I'll ask for that reviewer approval again.

[twitchy-jsonp]

I think I prefer consistency over correctness for something simple like an enum, and hence would prefer a consistent order. That said, if you are gunning to get this merged, I can leave it be, either way.

[langbeck]

Then I'll send a commit putting the new values in numerical order.
I still need to submit a commit with tests for this new API.
Right now I just want a signal that new change requests to this PR API are unlikely, so I can start working on doing the tests.

Note: I'm using this library in a project and I already have more changes/fixes to submit, but I can only do so after this one gets merged

[twitchy-jsonp]

Right now I just want a signal that new change requests to this PR API are unlikely, so I can start working on doing the tests.

@chrisfenner who is the expert here. LGTM.

[langbeck]

Enum reordered and tests completed. =)

[langbeck]

@chrisfenner @twitchy-jsonp @josephlr it does appear that you guys don't have much time do maintain this repo, so I would like to offer my help as maintainer.

I work at HPE and I've wrote a Go TSS package covering almost the same commands and types that you guys have here.
I've implemented all the calls following the exact inputs and outputs as described on TPM2 spec part 3 (thus would be no need to have those *Ex methods that we have here).
That version is HPE's property and I can't use it on opensource projects.

All this just is just an attempt convince you guys that I do have experience with TPM2 and that I'm able to help this project.
Cheers,
Dórian

[langbeck]

Could someone finish merging this PR, please?

[josephlr]

This is really great, I have a bunch of style nits, but no substantial issues.

Thanks for submitting this and sorry for the delay in review.

[josephlr]

@chrisfenner @twitchy-jsonp @josephlr it does appear that you guys don't have much time do maintain this repo, so I would like to offer my help as maintainer.

Thanks for the offer. If you want to help out with some existing pending PRs, we could totally look into adding you as a maintainer. My apologies that this review languished for so long. It's a good change that should have been quickly reviewed an approved.

We've been meaning to rework this library to autogenerate all the necessary code for all commands/structures from the Spec, but that effort has languished (mostly due to other stuff coming up at work). I would really like to get an autogenerated API, so that we don't keep having to add commands piecemeal.

I work at HPE and I've wrote a Go TSS package covering almost the same commands and types that you guys have here.
I've implemented all the calls following the exact inputs and outputs as described on TPM2 spec part 3 (thus would be no need to have those *Ex methods that we have here).

This is really cool. Needless to say, there aren't a ton of people who have the necessary expertise, so anyone willing to help is welcome.

[langbeck]

@josephlr I've just fixed the import and hashCount issues.
Before I do the "nit" changes please, allow me to quickly make a case in favor of the current coding style.
After doing some experiments with "non-Gophers" inside the company I noticed that, among other things, don't using inline features of the language and having space after a "logical block" of Go code considerably reduces the need for prior knowledge of the language in order to understand the problem solved by the code. This make it easier for non-Gophers, that does have knowledge of a technology, to review Go code.

If you still prefer the more condensed form, I already have the "nit" changes made and ready to Go.
Just let me know and I'll send the next commit with these changes.

Regarding the code generation, how far did you guys went?

[josephlr]

If you still prefer the more condensed form, I already have the "nit" changes made and ready to Go.
Just let me know and I'll send the next commit with these changes.

I totally get the point you're making here, but we generally shoot for consistency with respect to the style, and it seems like inline error handling (at least for shot statements) is somewhat the norm. I realize it's not perfect, but it's the approach I try to use across our projects.

If you could add the nit fixes, I can get this merged.

Regarding the code generation, how far did you guys went?

We should open up a tracking issue for this stuff. Long story short, we asked Microsoft to open-source the codegen tool they use for other languages, and they did. See: https://github.com/microsoft/TSS.MSR/tree/master/TssCodeGen

Their official process is quite complex, but we would ideally add Go to the languages currently supported, so that we can just generate the entire Go API surface at once.