vpeschenkov / securedefaults Goto Github PK

Description

I am using older version of SecureDefaults, in the process of upgrading to latest release.
I noticed SecureDefaults.secretObject() function makes use of NSKeyedUnarchiver.unarchiveTopLevelObjectWithData() which was deprecated in iOS 12.0.
Is it safe to use this function as I will be supporting iOS 17.4.1 users as well.

Requirements (place an x in each of the [ ])

• [x ] I've read and agree to the Code of Conduct.
• [ x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [x ] I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

SecureDefaults version:

iOS version:

Steps to reproduce:

Expected result:

What you expected to happen

Actual result:

What actually happened

Attachments:

Logs, screenshots, screencast, sample project, funny gif, etc.

Description

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__SwiftValue encodeWithCoder:]: unrecognized selector sent to instance 0x600002592800'
terminating with uncaught exception of type NSException

Requirements (place an x in each of the [ ])

• I've read and agree to the Code of Conduct.
• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

The reason of the crash is the following function:
private func setSecret (_ value: Any?, forKey defaultName: String) { if let value = value { let data = NSKeyedArchiver.archivedData (withRootObject: value) super.set (try? encrypter?.encrypt (data), forKey: defaultName) return } super.set (nil, forKey: defaultName) }

Only NSCoding conforming objects can be stored in NSKeyedArchive as far as I know.

Reproducible in:

SecureDefaults version: 1.0.7

iOS version: 15.5

Steps to reproduce:

1. set value with type that is not available for obj-c
2. get crash

Expected result:

It should save the value

Actual result:

crash

If someone was to delete the app off of their device. If they reinstalled the application would these key value pairs still exist and able to be retrieved?

Description

Application crashing if the object against some key is not of Data type, due to force type casting.

Requirements

• I've read and agree to the Code of Conduct.
• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

private func secretObject(forKey defaultName: String) -> Any?

Above method is to read some object from UserDefaults and its forcefully type casting objects to Data type.
If some older version of App or some other component has stored some other data type object in UserDefaults with same key, then application is crashing.

Reproducible in:

SecureDefaults version: 1.0.7

iOS version: 15.5

Steps to reproduce:

1. Store some object in UserDefaults other than Data type
2. Read the object using SecureDefaults using same key
3. Application will crashing, as its force type casting to Data type

Expected result:

If object fetched from UserDefaults is not of Data type return that object as it is, and return nil if nothing found, although the method is returning Any?

Actual result:

If fetched object is not of Data type application crashes

What actually happened

Attachments:

Description

When installing via carthage update, I receive the following error message:

Dependency "SecureDefaults" has no shared framework schemes

Totally could be something on my end, but I've tried installing this on a fairly vanilla project w/ Carthage and am receiving this error. Any guidance/hints as to what could be going wrong would be appreciated! 🙏

Requirements (place an x in each of the [ ])

• I've read and agree to the Code of Conduct.
• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Steps to reproduce:

1. Add github "vpeschenkov/SecureDefaults" == 1.0.3 to my Cartfile
2. Run carthage update

Expected result:

The framework is downloaded and built.

Actual result:

Error message:

Dependency "SecureDefaults" has no shared framework schemes

Description

Checking into the ~Library/Containers/myapp/Data/Library/Preferences/myappbundleid.plist file (the UserDefaults storage space) of my app, I see an unencrypted value, even though I used SecureDefaults. This kind of defeats the purpose of a secure alternative to stock UserDefaults.

Requirements (place an x in each of the [ ])

• I've read and agree to the Code of Conduct.
• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

SecureDefaults version: 1.0.6

iOS version: 15.3.1, 15.3, 15.2 (Tested Versions)

Steps to reproduce:

1. Store a value with SecureDefaults.standard.set("This value will be unencrypted.", forKey: "mykey")
2. If tested natively on Mac, go to ~/Library/Containers/, choose your app subdirectory and go to Data/Library/Preferences and open the .plist file with the app bundle ID as its name.
3. Check your key and its value, which will be shown in plain text, unencrypted.

Expected result:

An encrypted, unreadable and secure value.

Actual result:

A completely readable and unencrypted value that could be normally set by UserDefaults.

Attachments:

Demo Project
Demo App SecureDefaults.zip

Description

When using with Xcode 15 there are some deprecation warnings. The wrapper should be updated to the latest interfaces which do not result in compile time warnings when using Xcode 15.

Requirements (place an x in each of the [ ])

• I've read and agree to the Code of Conduct.
• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

SecureDefaults version: 1.1.0

iOS version: 16.4

Xcode version: 15.0 (15A240d)

Steps to reproduce:

1. Use Xcode 15 to build a project which uses SecureDefaults as a dependency
2. Look for the build warnings

Expected result:

No warnings when building.

Actual result:

There are 3-4 deprecation warnings.

Attachments:

Showing All Issues
 /<redacted>/SourcePackages/checkouts/SecureDefaults/Sources/SecureDefaults/SecureDefaults.swift:51:45: 'kSecAttrAccessibleAlways' was deprecated in iOS 12.0: Use an accessibility level that provides some user protection, such as kSecAttrAccessibleAfterFirstUnlock
 /<redacted>/SourcePackages/checkouts/SecureDefaults/Sources/SecureDefaults/SecureDefaults.swift:265:42: 'unarchiveObject(with:)' was deprecated in iOS 12.0: Use +unarchivedObjectOfClass:fromData:error: instead
 /<redacted>/SourcePackages/checkouts/SecureDefaults/Sources/SecureDefaults/SecureDefaults.swift:273:40: 'archivedData(withRootObject:)' was deprecated in iOS 12.0: Use +archivedDataWithRootObject:requiringSecureCoding:error: instead

Description

First of all, thanks for this package! Please forgive me if this question seems uninformed, as I'm somewhat new to iOS development.

I'm wondering how best to use the keychainAccessible attribute. I see that it can be set after initialization, which I'm glad for, since I'd like to set it to kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly rather than the default of kSecAttrAccessibleAlways. However, if I change this value after the initial instantiation, I'm met with various crashes such as this one if I set the accessibility before checking if a key is created:

Or this one if I set the accessibility after checking:

As far as I understand, a keychain item's accessibility cannot be modified in place, so I'm not terribly surprised this doesn't Just Work™, but is there a way to guard against these crashes? As some additional context, I'm wrapping SecureDefaults to be used in a React Native package, and I'm wondering if there is a way to bubble the [expected?] error to the user so that they can deal with it rather than having a hard requirement that the kSecAttrAccessible value never be changed for a given suite. Or maybe this will have to be code I'd write outside of SecureDefaults before it is instantiated?

Requirements

• I've read and agree to the Code of Conduct.
• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've searched for any related issues and avoided creating a duplicate issue.

Reproducible in:

SecureDefaults version: 1.1.0
iOS version: 16.1

Steps to reproduce:

1. Instantiate a SecureDefaults shared instance using a suiteName and some value for keychainAccessible
2. Set values, etc.
3. Dynamically change the keychainAccessible value
4. Attempt to access a value stored in SecureDefaults

Expected result:

Not exactly sure, honestly!

Actual result:

Crash!

Description

I am working in WatchOS, unable to add SecureDefaults pod

What actually happened

-> The platform of the target xxx Watch App (watchOS 8.0) is not compatible with SecureDefaults (1.1.0), which does not support watchOS.

Can we add watchOS support?