-
Notifications
You must be signed in to change notification settings - Fork 3
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
Share release credentials? #30
Comments
If I'm not mistaken the only way to push stuff to Specs today is with an email and password right? If there would be some secret/private key pair we could use to do this, it would've been much nicer in this sense (of an organization). Anyways using a shared user/pass could work but feels like there should be a nicer way. |
Yeah, I should have mentioned how CocoaPods authenticates trunk pushes. It uses a The thing is, $ TRUNK_EMAIL=... TRUNK_TOKEN=... pod trunk push Action.podspec But that doesn't exist in CocoaPods right now. Anyone up for sending a PR? 😉 |
Basic auth meaning we need to have a single email and password, pretty much - right ? |
I think you won't need the |
@freak4pc yes exactly. @bobgodwinx I believe we need both, as the token authenticates the email, which is used to check if the email has push access to the pod. |
@bobgodwinx This isn't something like OAuth unfortunately, so the authentication is sort of a "one off", and you always need the email/pass pair to push a version up. Anyways I think we're on the same page, we'll probably need to do some work on Cocoapods itself before we can make satisfy this demand. |
Ah ok I get it. This means only people added to the |
Any update on this issue? |
I haven't had time to look into it further, I probably won't have time soon but if someone else has availability, let me know what I can do to support you. |
The problem with this ticket is its really not straightforward ... every choice of how to do this will be a tradeoff. (Mainly security-wise?) |
If I may add something, shared credentials is of course the easiest and most straight forward solution here. However, it just feels wrong! Something inherently says No about it. Again, this is just a feeling/how-we-used-to-stuff thing so if we need to ignore this and proceed with it, we absolutely can. On another hand, I see this is a typical bus factor problem. I may suggest simply adding an item to the checklist of adding another 2-or-more active members of the organisation on Cocoapods. So while original author may remain as the main maintainer of repo, others may help pushing new versions once needed. IIRC there was a similar case happening soon regarding RxMKMapView and involving @freak4pc & @icanzilb where this mechanism actually worked. |
I ran into this article and I think it could help. Let me know what you guys think. |
Sounds good to me! It will take a bit of setup but I like this. I won't have time to look at it for a few weeks, if anyone finds other materials that would help, chime in :) |
I've also bumped into this: https://www.vaultproject.io/intro/index.html |
We have a bunch of projects and they're all released fairly similarly: tag, push, and send to CocoaPods Trunk. We should have some way for org members to step in and help deploy any RxSwiftCommunity library.
I have a few initial ideas, but this discussion is very open-ended, so chime in!
Maybe we could have a centralized RxSwiftCommunity CocoaPods Trunk account and share credentials securely through Keybase?
The text was updated successfully, but these errors were encountered: