Closed scasplte2 closed 8 months ago
I am unsure of the correct tag that would apply here so any suggestions are welcome.
Motivation to do this is that I am getting a merge error during assembly for the flight-data metagraph. Bumping the dependency version seems to resolve without causing any compile or test errors.
there is another PR for http-request-signer
to also bump to 1.75, which I believe would resolve the duplication error causing two of the tests to fail. This is a similar error to what I am getting on the other metagraph since I am pulling in two dependencies which themselves rely on updated version of Bouncy Castle (one of which is blocking me from proceeding at the moment)
Not saying we shouldn't do it, but we need to be careful it doesn't break anything - for example if the old keys created with old bouncy castle can be still used (or at least migrated). BC is used at the very core of the application.
I agree with @TheMMaciek. I would be super careful touching the bouncy castle library. We've had issues in the past with incompatible keys. IMO we should keep the BC version consistent so if you need it to bump, probably it should be updated in all places but firstly double checked the changelog to figure out potential compatibility issues.
Thanks for the feedback. I agree that care should be taken when dealing with the cryptographic infrastructure. I ran sbt dependencyTree
and did some analysis of the dependencies to find that 1.75 seemed to standardize the bouncy castle version across most of the dependencies in the flight-data
project. I should dig further to confirm if bouncy-castle is present at any higher versions but I will need to report back.
Regarding the historical keys, could this be tested by generating an updated application and having it join Testnet?
Bumps bouncy castle up to 1.75, all tests pass via
sbt test
.