-
-
Notifications
You must be signed in to change notification settings - Fork 21
Switch to Travis's new authentication/integrity check scheme #43
Comments
I believe this is related. travis-ci/travis-ci#6435 |
Looking at twbs/bootstrap#21736, as an example, we can see that the statuses from Savage are not being updated prior to merging. :-( |
Your analysis is correct. I haven't had much time for Savage lately, and so the Authorization header logic is outdated relative to Travis's awesome bugfix. |
Certainly not your burden to carry alone @cvrebert. I took a rough stab at implementing the update authorization technique, but ultimately ran out of time due to my lack of Scala knowledge. |
Yeah, PRs welcomed. I'm happy to translate to Scala from Java if necessary. |
I also have no Scala knowledge (yet), but am willing to put a few hours into it. |
I've waded out about as far as I can, I think. I opened a WIP PR against my own branch that makes the changes that were obvious to me and lays out TODOs for what I think is left. Anybody is welcome to try to take it from there (no guarantees that Base64 stuff works), but I'll keep plugging away at it as I get time if no one else does: https://github.com/bobholt/savage/pull/1/files |
Assuming we pull in BouncyCastle for the public-key crypto, the verification part should start with doing I am less clear on how to read Travis's public key into a |
Okay, think I've got the crypto part all figured out now. PR incoming. |
To be used for Travis's new authentication mechanism Refs #43
To be used for Travis's new authentication mechanism Refs #43
…stle To be used for Travis's new authentication mechanism Refs #43
This theoretically addresses #43, though ideally we should fetch Travis' public key ourselves rather than requiring the user to copy it into the settings file themself.
This theoretically addresses #43, though ideally we should fetch Travis' public key ourselves rather than requiring the user to copy it into the settings file themself.
This theoretically addresses #43, though ideally we should fetch Travis' public key ourselves rather than requiring the user to copy it into the settings file themself.
To my knowledge, our setup/configuration hasn't changed, but we now consistently get "Received Travis request with incorrect hash!"
This in turn causes the status / comment to not be updated / posted on the PR. Looking at Bootstrap, it appears maybe you're seeing the same behavior?
The text was updated successfully, but these errors were encountered: