XCode Certificate and Provisioning Error

Note to self and anyone else that runs into this -

Today XCode 4 refused to build a project that used to build just fine till the last time I had opened it. A cryptic "Cannot find [pretty long string] profile".

After a bit of investigation, it turned out that my Developer certificate from Apple Developer Program had expired. Renewing and downloading the new certificate still did not solve the problem.

Keychain still had my old expired certificates in addition to the new ones. I was assuming that the new ones would start getting used but the existence of the old ones was causing XCode to still use them.

Finally, deleting all the expired certificates solved the issue.

WiFi Files

THIS PAGE HAS MOVED TO Files n Folders

The content below is maintained for legacy purposes only. 





WiFi Files is a utility app that lets you transfer files, images, videos from your personal computer to and from your mobile device over WiFi.


The app runs on iPhone, iPod Touch and iPad.

Features
DOWNLOAD & UPLOAD
* Browse folders and download files from both Mac and Windows machines to your device
* Upload files, photos & videos from your iDevice to your Mac or Windows machine

ZIP FILES
* Unzip saved compressed files on your device
* Create zip files from folders on your device

DO MORE WITH SAVED FILES
* Save files from other apps. Example, you can save attachments from Mail in the app for later access, save zip files from attachments and then unzip them.
* Organize saved files into folders via drag n drop
* Email saved files as attachments
* Sort file lists alphabetically and by modification date
* Add downloaded images and videos to the Photos app on your device
* Video AirPlay support

* Allows opening of different file types in other apps that support the file format

INTERNET FILES
* Browse the internet and save files from the web
* Save webpages as HTML or as PDF
* Capture and save web screenshots


Troubleshooting

• Username/Password issues: The username is case-sensitive and cannot contain a space. The newer version (April 2, 2012) desktop app checks for this issue but older versions and the iOS app does not validate this. Will be fixed in a future release of the iOS app.
• Ensure that the HTTP Service on the desktop app shows the status of "Started". If not, the iOS app cannot connect. 
• The desktop app requires the port 48080 to be available to start the HTTP service. 
• Try "Restarting Services". Sometimes if the desktop app is running for a long time, the IP address expires and must be renewed. The newer version of the desktop app (April 2, 2012) solves this issue. 
• Check that you have entered the IP address correctly on iOS devices.

UnixCrypt produces same values for different passwords

This is interesting. Learnt something new today.

I've been using the UnixCrypt class from Jetty and if the first eight characters of the password to be encrypted are the same for two passwords, the resulting encrypted (hashed) value is the same.

I was trying to reproduce an error message in my program by providing the wrong password and creating the wrong password by simply modifying the last character of the password. However, inspite of supplying the wrong password, the system was successfully authenticating.

The problem was that two different passwords like John1234$ and John1234b#, were producing the same value from UnixCrypt which was leading the system to think that it was the correct password. BTW, notice that one could potentially call these passwords quite strong given they have an Uppercase, lowercase, numbers, a special character and are greater than 8 characters.

The only way to get different values is to use completely different salts. But even there is a catch. Salts like '12abc$1' and '12gfd#2345' though completely different, produce the same value.

I've been using the class as part of a program that saves passwords and was using a salt of format - "constant + random". This was resulting in same value even though the salt was technically different. Here is a test program and the resulting output - (some boilerplate code omitted for brevity)

Code

String password = "John1234$";

String salt = "12abc$1";

String val = UnixCrypt.crypt(password,salt);

System.out.println("(" + password + "," + salt + ")" + " = " + val);

password = "John1234b#";

salt = "12gfd#2345";

val = UnixCrypt.crypt(password, salt);

System.out.println("(" + password + "," + salt + ")" + " = " + val);

Output

(John1234$,12abc$1) = 12FH7.yEd/XWI

(John1234b#,12gfd#2345) = 12FH7.yEd/XWI

Why is this happening even when the salts are completely different? The problem is again the prefix. Looks like if the first two characters of the salt are same, the same value is produced. Simply altering the second character of the salts, '12abc$1' and '13gfd#2345' , results in different values.

New Output with second character of the salt changed -

(John1234$,12abc$1) = 12FH7.yEd/XWI

(John1234b#,13gfd#2345) = 13uN.eBnCs5io

Ideally, the salts should be dynamically generated. However, even if that is done, likelihood of a collision is quite high due to the small size of the salt prefix.

At this point the only certain way around that I can think of is to ensure that two passwords don't have the same first 8 characters.

When I get time it will be good to look into why this is happening. A little bit of browsing around the web told me that this might have something to do with the MD5 hashing algo but that is an exploration for another day.

How about a Java app store?

Thought Process

The Apple Mac store is a very interesting development. Apple is trying to bring the iPhone like experience to the Mac - the traditional "desktop".

One of my iOS apps has a desktop component and it got me thinking that if I had to make the desktop component available in the Mac App store it would need to be re-coded in Objective C and Cocoa and then again in .NET for Windows. Based on the downloads, my audience for the desktop app is about evenly split between the two platforms - OSX and Windows. That makes it impossible for me to ignore either of the platforms.

Right now the app is an Eclipse-based RCP app, which solves my issue of coding for multiple platforms - OSX and Windows. I write the code once and just create two native builds. Being a stripped down RCP app with minimal plugins and inspite of being a Java app, I think it performs quite well on the desktop.

My next thought was that it would have been great if there was an consumer focussed "App-store" for Java apps that brought the same experience the iOS devices bring to mobile. Java does take the pain out of coding the app logic twice. While there are some compatibility issues, it cannot be as bad as writing code twice and trying to ensure coherency in the logic between two lines of code.

What is required?

A thin operating layer on the desktop that simply provided access to the lower filesystem, provided a security sandbox and allowed for extensions.

Here are some of the characteristics that I can think of -

• An "App Store" app to find apps natively from within the desktop and do a one-click install.
• Standard features in App Stores - ability to rate and review, feature, popular, ….
• Ability to view all running apps, switch between them, kill them, …
• Support for different kinds of apps types - widgets, full-blown apps, …
• Preferably a unified app store instead of the user having to search multiple sources (i.e. preferably the iPhone experience vs Android experience)
• Integrated eCommerce to sell apps and their features - An idea would be to integrate the plugin store with providers like PayPal, who have already solved this issue. Making a user go to multiple sites to make payments would not be a good experience. This is something Apple does well with iTunes - they make it easy to buy and install something immediately. Amazon does this well for various sellers on the web.
• Other good features would be - in-App purchasing APIs, recurring payments, app sandboxing.
• Developer guidelines with a focus on user experience and good looking apps.

How to set this up?

Make it Eclipse-based or Eclipse-like or OSGI-based

Eclipse already has a few good things going for it

- A solid plugin model. Plugins would be similar to Apps

- A fairly decent update mechanism

- There is already an Eclipse Marketplace. However, it is too IDE and developer focussed (it prompts to login with my "Bugzilla" ID :))

However, other than the IDE, Eclipse does not have a killer app that users will want to download and install on their desktops. The IDE is certainly not a killer app for consumers. Thus, Eclipse will need a killer app that will put the App control layer and marketplace apps on a users desktop.

Use JRE to distribute this Eclipse-based control layer and marketplace app

Integrate this operating app and the marketplace store app inside the JRE itself. With every download of JRE, users also get the ability to extend their JRE experience with plugins. However, the UI component will need to be SWT-based and not Swing based. Eclipse, in my opinion owes a lot of its success to SWT and JFace. There were free IDEs before Eclipse but reason I (and probably a lot of people) switched to it was due to its native look n feel and performance.

Who could make this happen?

Probably Oracle in cooperation with other Java supporters such as IBM, Google, Eclipse ...

In Summary

- Great to have a Java-based consumer focussed app store platform

- Borrow features from mobile devices such as sandboxing, integrated eCommerce.

- Eclipse-like plugin model except absolutely no IDE components

- Integrated with the JRE download