> Then think about how much a security audit would cost.
This is why some customers require various security certifications. Too bad the certifications often focus on whether your employees have three groups of characters in their passwords instead of an actual security audit with penetration testing.
My point being, how to make people want a proper audit and how to commuicate you had one. From another point of view, how do you justify the cost without including the risk of being hacked? Because even in this instance, they were (probably) not hacked, and your reward was likely lower than an audit would cost.
We only need CocoaPods, because Apple couldn't build a proper package manager for XCode. And I am quite sure event Apple uses CocoaPods internally.
CocoaPods itself is quite problematic: You need Ruby to run it. Definitions aren't strict enough (you can use too old CocoaPods binary for package that doesn't support it). Pods can cause build conflicts/issues that might only be visible when you run your app.
Swift Package Manager is the official package manager for Xcode. It's been available for a few years now and a lot of third party iOS/macOS projects support it. I haven't had to touch CocoaPods in many years. For the past 5 years I've been using Carthage, and more recently everything is SPM.
Not to mention that things like stats (useful for assessing quality) and search ranking have been broken for years [1].
This isn't meant as a criticism of the CocoaPods team, who seem to be doing the best they can given that they're working on a volunteer basis and even had to pay for infrastructure costs out of pocket. It just amazes me that Apple couldn't donate a little bit to help out such a critical part of their developer ecosystem.
I think the success and rapid adoption of Swift Package Manager as it has become a viable solution speaks to this deep desire in the community to have an Apple provided solution to it.
CocoaPods was a hugely important part of the iOS ecosystem and will be for years to come, but SPM is a great next step.
SPM has a lot of issues, though. For example: if you depend on a static library, it will both statically link it _and_ embed the binary; likewise, a static library dependency in a framework will cause build failures ~70% of the time when clean. There's others around resources, etc.
I do not believe SPM is mature enough to be the entire platform, and worst yet if you experience any problems it is entirely impossible to customize the behavior. I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries -- SPM works for the most basic use cases, but not all.
I don't use CocoaPods because
a) they are a gaping supply chain vulnerability and
b) they lead to bloat as people routinely pull in a whole package for one routine.
I manually import and rewrite snippets of 3rd party code when needed, or I write needed utils myself. I lean on the OS as much as possible, not dodgy and often abandoned 3rd party libraries.
Looks like they've made an web-app (https://pod-sources.cocoapods.org/) to check the distinct sources of a pod so you can have a fish to see if a source location url changed behind your back.
Would be good to show a list of all repositories where there are more than 1 distinct source as most people who make pods just point to their Github repo release page.
It's very tedious to check the impact of this without that list.
I noticed that quite a few pods have more than 1 distinct source when checking the pods used by projects I have worked on. From what I could see source changes were the result of ownership changes, GitHub account name changes, etc.
So i'm not sure how to distinguish malicious source changes from innocuous ones. Maybe it would be worthwhile to search for source changes that lasted a single release and reverted thereafter.
It's an issue with "the UNIX way". I'm not bashing on composability, but the fact that "the UNIX way" is just composability delivered in a bloated, error prone way.
Specifically, the problem here is that git, like almost every other CLI tool, tries to add as many features as possible to make it easy to use from a console. This (coupled with the fact that these things are never documented, as is the case here, unless <exec> is some idiom I'm supposed to be aware of) makes it harder to use in a correct manor (security bugs being a subset of possible problems).
Honestly surprised this wasn't about some internet connected coffee machine!
I expect you could make a hard developer trivia game where people have to guess if a vulnerability was found in an IOT app or a SAAS app based only on the name.
[+] [-] justicz|4 years ago|reply
I started looking because I wanted to find bugs in Signal for iOS, which uses CocoaPods: https://github.com/signalapp/Signal-iOS/blob/master/Podfile
[+] [-] rplnt|4 years ago|reply
This is why some customers require various security certifications. Too bad the certifications often focus on whether your employees have three groups of characters in their passwords instead of an actual security audit with penetration testing.
My point being, how to make people want a proper audit and how to commuicate you had one. From another point of view, how do you justify the cost without including the risk of being hacked? Because even in this instance, they were (probably) not hacked, and your reward was likely lower than an audit would cost.
[+] [-] dang|4 years ago|reply
[+] [-] sigg3|4 years ago|reply
> I’m trying to give 10,000 mosquito nets to charity! If you liked this post please consider donating a $2 mosquito net.
https://giveanet.org/
[+] [-] ksml|4 years ago|reply
[+] [-] kirby88|4 years ago|reply
[+] [-] mcraiha|4 years ago|reply
CocoaPods itself is quite problematic: You need Ruby to run it. Definitions aren't strict enough (you can use too old CocoaPods binary for package that doesn't support it). Pods can cause build conflicts/issues that might only be visible when you run your app.
[+] [-] lyptt|4 years ago|reply
[+] [-] jonas21|4 years ago|reply
This isn't meant as a criticism of the CocoaPods team, who seem to be doing the best they can given that they're working on a volunteer basis and even had to pay for infrastructure costs out of pocket. It just amazes me that Apple couldn't donate a little bit to help out such a critical part of their developer ecosystem.
[1] https://github.com/CocoaPods/cocoapods-stats/issues/32
[+] [-] danpalmer|4 years ago|reply
CocoaPods was a hugely important part of the iOS ecosystem and will be for years to come, but SPM is a great next step.
[+] [-] marcusbuffett|4 years ago|reply
[+] [-] jquery|4 years ago|reply
I’d be very surprised if Apple wasn’t dogfooding their own tool chain
[+] [-] ChrisMarshallNY|4 years ago|reply
I'm deprecating my use of Cocoapods (for publishing -I never use them for my own software), in favor of SPM.
That said, it's clearly a labor of love, and filled an important niche for years.
[+] [-] zacwest|4 years ago|reply
I do not believe SPM is mature enough to be the entire platform, and worst yet if you experience any problems it is entirely impossible to customize the behavior. I think it's going to be another year or 2 before dropping CocoaPods entirely is a fair choice for libraries -- SPM works for the most basic use cases, but not all.
[+] [-] w0mbat|4 years ago|reply
I manually import and rewrite snippets of 3rd party code when needed, or I write needed utils myself. I lean on the OS as much as possible, not dodgy and often abandoned 3rd party libraries.
[+] [-] eddieh|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] AJRF|4 years ago|reply
Would be good to show a list of all repositories where there are more than 1 distinct source as most people who make pods just point to their Github repo release page.
It's very tedious to check the impact of this without that list.
[+] [-] algoma|4 years ago|reply
I noticed that quite a few pods have more than 1 distinct source when checking the pods used by projects I have worked on. From what I could see source changes were the result of ownership changes, GitHub account name changes, etc.
So i'm not sure how to distinguish malicious source changes from innocuous ones. Maybe it would be worthwhile to search for source changes that lasted a single release and reverted thereafter.
[+] [-] xucheng|4 years ago|reply
[+] [-] tantalor|4 years ago|reply
They should have used `popen` instead.
This is similar to python's subprocess with `shell=True`
Edit: I'm wrong!
> ls-remote has a parameter --upload-pack which can be used to execute a new shell
[+] [-] qyi|4 years ago|reply
Specifically, the problem here is that git, like almost every other CLI tool, tries to add as many features as possible to make it easy to use from a console. This (coupled with the fact that these things are never documented, as is the case here, unless <exec> is some idiom I'm supposed to be aware of) makes it harder to use in a correct manor (security bugs being a subset of possible problems).
[+] [-] pabs3|4 years ago|reply
https://www.defensecode.com/public/DefenseCode_Unix_WildCard...
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] QuercusMax|4 years ago|reply
[+] [-] dang|4 years ago|reply
[+] [-] SiempreViernes|4 years ago|reply
I expect you could make a hard developer trivia game where people have to guess if a vulnerability was found in an IOT app or a SAAS app based only on the name.
[+] [-] amelius|4 years ago|reply
Whenever IT folks run out of good names they always turn to coffee.
[+] [-] hashmush|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]