Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump supported version #207

Open
ionut-arm opened this issue Mar 16, 2021 · 5 comments
Open

Bump supported version #207

ionut-arm opened this issue Mar 16, 2021 · 5 comments
Labels
enhancement New feature or request
Projects

Comments

@ionut-arm
Copy link
Member

We're currently targeting version 2.3.3 of the library, with versions 2.4.0 and up probably having an inconsistent API with our abstractions.

There are a couple of options for us to move forward - we can either drop support for 2.3.3 completely and simply continue with 2.4.0, or we can try and keep them both alive as features.

@ionut-arm ionut-arm added the enhancement New feature or request label Mar 16, 2021
@ionut-arm ionut-arm self-assigned this Mar 16, 2021
@ionut-arm ionut-arm added this to All issues in Parsec via automation Mar 16, 2021
@hug-dev
Copy link
Member

hug-dev commented Mar 17, 2021

Also to keep in mind that RHEL uses 2.3.2.

@ionut-arm
Copy link
Member Author

I've tried it locally - just pulling the current tip of master of this repo and running the all-ubuntu.sh with various versions installed, 2.3.2, 2.3.3, 2.4.0 all seem to pass all tests. @Superhepper - was there some specific use case that failed for you for 2.4.0? Maybe I'm testing the wrong thing.

For Parsec I've tried all those versions as well (though with the latest release, not with the current state). 2.3.2 clearly fails to work (because of a bug that was fixed in 2.3.3). 2.4.0 does work. I'll try using the current tip, see if it still works.

@Superhepper
Copy link
Collaborator

Superhepper commented Mar 17, 2021

@ionut-arm
Nah, I changed the code previously in order to make it work will all versions. So instead of using the correct interface type when converting a native interface type to a TPM interface type ( because the correct TSS interface type had the wrong name) I used some kind of 'base type' and as I said previously it is not something critical. Because so far I have not found something so fundamentally broken that it cannot be fixed with a little bit of a hack. But it would be nice to be prepared.

It is a little bit inconvenient and it makes things less consistent though not something a user would recognise.

@Superhepper
Copy link
Collaborator

Also to keep in mind that RHEL uses 2.3.2.

I know it was a real pain that we support 2.3.3 and RHEL supports 2.3.2 that is something that I have had to deal with.

@ionut-arm
Copy link
Member Author

Ok, we can keep this open for now with no pending action just yet

@ionut-arm ionut-arm removed their assignment Apr 22, 2021
tgonzalezorlandoarm pushed a commit to tgonzalezorlandoarm/rust-tss-esapi that referenced this issue Mar 14, 2024
Create `Connection` abstraction for client communication
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Parsec
All issues
Development

No branches or pull requests

3 participants