Add 'pss_salt_length' parameter in transit/sign endpoint (#7531)

[mbreban]

trafficstars

[hashicorp-cla]

All committers have signed the CLA.

[jefferai]

I think this could be significantly simplified by passing the string value from the parameter into the sign function and doing a simple switch on the string value, without needing to define the constants and constant maps. Or, alternately, keep the map but map to the existing Go stdlib constants instead of redefining them locally.

I also think if this is being implemented we should accept a string number as well. So we check if the string is "auto" or "hash" and if it's not either we attempt to parse (a non empty string) as a number, and if successful use that as the length.

[mbreban]

Hello @jefferai I fixed my previous PR. Please let me know about the new implementation.

[jefferai]

I think it'd be better with a different type that can allow both integers and strings At this point though the CLA is outstanding so until that's signed I'm going to hold off on any further review.

[mbreban]

I did sign the CLA one month ago.

[jefferai]

Hmm it's showing here as not signed. I can ask someone to look into it. Could you also try it again just to be sure?

[chrishoffman]

When it is showing as not signed, it usually means the email attached to the commit does not match your github account. It will require you to force push so that the history only shows the matching email address.

[jefferai]

Oh good point @chrishoffman , forgot about that

[mbreban]

Hi @jefferai, By saying "a different type that can allow both integers and strings", do you mean using the interface type? Should the function pathSignWrite pre-process the data or should it be done only by the Sign function?

[grembo]

@jefferai I would like to pick this up, how to approach this best - should I simply start a new pull request?

[stevendpclark]

Hello @mbreban, thanks for the original contribution. I'm closing this PR out as it has been implemented and merged within #16549.