-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Support for SPKI #3269
Comments
We've discussed adding SPKI support in the past. However, due to the complexity of the feature we decided not to merge the existing PR. Instead, we feel that the feature needs to be built by the Alamofire core team itself, both to develop the expertise necessary to implement and maintain the feature long term, as well as to mitigate the risk of the feature by developing it within the foundation. So while we think the feature would be a useful addition to Alamofire, its complexity, risk, and lower community value have prioritized it lower than our other work on the library. I'll keep this issue open to track the feature. If anyone has important services or use cases that would benefit from this feature, please let us know. |
Thanks for following up on this and for keeping this open for visibility. I'll update the issue description with data from #2678 so anyone jumping in can understand what the feature is about. It's a shame the original pull request did not make it. I understand the reservations of the maintainers even if I disagree (I think with a few changes the PR could probably reach a testable enough state to be included as an experimental feature.) Since the current decision is that this is something only the maintainers can do, could you help me understand how the team currently prioritizes feature requests? What should the community do to indicate they see value in this feature? Best, |
To be clear, there wasn't necessarily anything wrong with the original PR. It's just that, given the risks involved, we decided we should build the feature ourselves. We can't really ship experimental security features in a library as widely used as Alamofire. If anyone really wants the functionality provided by the PR, As to feature prioritization, there is no formal process, but there are a few considerations that must be balanced.
Every choice to work on a feature is done balancing those concerns. For this SPKI functionality, the time it would take to become comfortable with the standard and implement a solution, the complexity of the solution and testing, the ability for users to build it outside of Alamofire, it's relative unpopularity (it's not even an accepted IETF standard), and riskiness of the feature are all considered in making it a lower priority feature. |
Hi @jshier did you get any solution for SSL pinning without certificate or certificate data? I want to do SSL pinning using alamofire but by using jus public key. |
@rohitdhawan As someone who previously asked for this feature, here are some points: Certificate Pinning has recently fallen out of favour quite drastically amongst Info Sec specialists. I would advise reviewing the following article prior to doing it: https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning Should you choose to pin anyways then I would advise the following alternatives to accomplish SPKI pinning:
struct TrustKitServerTrustEvaluator: ServerTrustEvaluating {
let trustKit: TrustKit
func evaluate(_ trust: SecTrust, forHost host: String) throws {
let result = trustKit.pinningValidator.evaluateTrust(trust, forHostname: host)
switch result {
case .shouldBlockConnection:
throw AFError.serverTrustEvaluationFailed(reason: .publicKeyPinningFailed(host: host, trust: trust, pinnedKeys: [], serverKeys: []))
case .domainNotPinned, .shouldAllowConnection:
return
@unknown default:
return
}
}
} Best! |
@CaioSym a Big Thank you for your reply :). |
Sorry for opening a separate issue for this. I'm trying to draw attention to #2678 which has been closed but seems to have no clear resolution. The PR for it was never merged (#2680) but the issue seemed to be going in a favorable direction for adding support.
If there is no interest in adding SPKI support to alamofire perhaps we could close the PR and state so in the original issue so that future users will know not adding it was a deliberate decision.
Should the maintainers believe SKPI support has value, could we perhaps reopen the original issue until the PR is merged?
Best,
The text was updated successfully, but these errors were encountered: